►
From YouTube: Kubernetes SIG Auth 20180711
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180711
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
C
D
E
C
C
This
is
a
duck
that
was
shared
by
Greg
Castle
last
year
around
what
our
plan
for
secrets
in
Kiruna
days
should
be,
and
then
looking
at
my
dog
and
updating
it
for
you
know
a
year
later.
What
what
could
we
do
going
forward?
It's
not
at
all
over
committing
to
doing,
but
what
could
we
do?
Give
him
the
changes
that
have
happened
in
the
last
12
months.
C
Some
of
the
some
of
the
key
principles
that
Greg
had
outlined
around
encryption,
for
example,
haven't
significantly
changed
and
that
we've
added
database
encryption
layer,
options
of
1.7
and
kms
plugin
doesn't
110,
but
secrets
are
still
not
encrypted
by
defaults.
A
mutual
loss
hasn't
significantly
changed.
Lee's
privilege
has
improved.
Auto
logging
has
significantly
improved,
there's
still
no
rotation
functionality,
then
we've
it
added
some
additional
things
that
we'd
like
to
consider
such
as
time
loaded
acts
as
a
revocation
usability
hasn't
significantly
changed
around
having
a
consistent
API
version
management,
etc.
C
C
There
is
a
house
record,
vault
cameras
plug-in
that
I
think
KK
from
Oracle
is
working
on
so
I
believe
that
should
be
published
shortly
yeah
and
then
we
talked
about
possibly
doing
sorry
moving,
that
kms
plug-in
to
beta
updating,
some
of
the
other
kind
of
internal
or
external
store
or
store
office,
etc.
I
think
some
of
the
major
design
decisions
me
to
make
or
do
we
want
to
have
a
way
of
natively
you
know,
do
we
want
to
build
a
more
full
feature
in
secret
management
solution
into
kubernetes
I
posit?
C
E
E
One
question:
does
anyone
oski
from
the
fall
team?
One
question
is
I
know
that
in
the
document
there
are
discussions
on
for
the
enhanced
automata
for
Caretti
secrets
and
it
seems
like
there's
channel
store
or
internal
superstore
communities,
but
there's
a
desire
to
sort
of
unified
like
basic
security
principles
around
like
the
API
or
especially
within
the
automata.
Simply
do
we
have
an
example
like
what
these
female
would
be
for
that
bought
along
with
regards
to
security
events
together,
you.
D
C
C
E
Right
yeah,
but
more
I,
guess
more
directly
with
relationships
raised.
Do
we
have
an
example
of
just
the
schema
that
you
raise
as
I'm
using
for
tracking
security
events
like
within
kubernetes
secrets
itself
before
it
even
hits?
The
external
secret
starts
because
I
feel
like
from
like,
for
example,
within
golf.
If,
if
there's
there's
work,
the
probably
needs
be
done
on
whatever
the
external
secret
stores
and
to
make
sure
that
easier,
more
intelligible,
understand
perspective.
It's.
A
There's
nothing
security
specific.
As
far
as
audit
logging,
the
audit
logging
is
API
centric,
and
so
these
log
events
that
we
would
be
producing
would
be
the
same
for
secret
objects
as
for
any
other
type
of
object.
So
they
have
it
pulled
up
on
the
screen
share
right
now,
but
at
the
metadata
level
you
get
the
user,
the
may
the
request,
the
source,
the
timestamp
and
then
the
details
of
the
API
request
they
made,
but
not
the
contents
either.
C
C
C
It
requires
adding
a
lot
of
functionality
into
kubernetes
core,
which
doesn't
necessarily
need
to
be
there.
I
haven't
seen
a
lot
of
customers
who
are
interested
in
having
multiple
difference.
You
could
stores
at
once
and
I
just
want
to
get
feedback
on.
Is
this
something
we're
still
interested
in
pursuing
it?
There's
a
lot?
That's
maybe
you
have
other
other
ways
with
dress
I.
B
E
B
Would
be
in
favor
of
working
on
integrations
with
your
stores
that
people
are
already
using
rather
than
rebuilding
or
enhancing
kubernetes
secret
functionality.
It
filled
a
gap
in
our
user
experience
very
early
on
and
I
think
there
are
other
tools
that
handle
secrets
better
than
we
can
or
will
be
able
to
in
a
foreseeable
future.
A
C
A
Partitioning
that
you'd
want
to
be
a
fundamental
part
of
a
secret
integration,
so
I
think
if
you
did
integrate
or
enhance
the
kubernetes
secret
API
to
plug
into
some
of
these
back-end
things,
the
characteristics
of
the
API
would
mean
you
would
have
to
do
things
that
you
wouldn't
want
to
do
like
extract
and
decrypt
and
expose
all
secrets
uniformly
and
we'd
be
back
in
the
same
boat.
We're
in
today.
F
A
C
F
All
right,
I'm,
sorry,
yes,
I
was
still
thinking
about
the
not
knowing
that
currently
I
wasn't
thinking
that
that
you
know
a
city,
it
could
be
like
a
v2
API
that
sort
of
goes
a
different
direction.
If
that
was
those
case,.
B
F
F
The
other
solution
there's
also
envelope
encryption,
which
the
kms
provider
does
now
and
where
you
could
have
that
kind
of
enhanced
to
do
like
her
perky
context
or
perky
kind
of
derivation
or
something
but
I
think
that
there's
likely
to
be
and-
and
you
know
not
a
totally
unbiased
Freddy
here-
there's
a
dome.
You
know
me
I'm
on
the
ball
team,
but
I
think
that
there
are
there's
likely
to
be
interesting
things
that
can
be
done
if
there
can
be
kind
of
an
alternate
way
to
integrate.
F
B
F
F
Couple
of
things,
so
one
is
that
I
think
and
it's
somewhere
in
this
document.
I
forget
if
it's
up
or
down
from
here,
but
some
of
the
new
API
is
it
currently
in
alpha
that
will
allow
kind
of
better
granularity
or
plan
to
incorporate
it
into
their
yeah
pod
identity.
It's
good
service
code
opens
so
there's
a
number
of
things
so
we're
working
on.
F
We
have
some
kind
of
a
very
old
and
formally
closed
source
kind
of
helper
that
that
we
are
open
sourcing
and
modernizing
that'll,
make
it
fairly
trivial
to
get
a
token
from
a
pod.
So
it
basically
does
this
workflow
for
you.
So
you
can
just
say,
like
you
know,
I
want
to
have
this
says
in
it
or
sidecar
container
and
run
this
binary
in
the
binary
will
say:
ok,
I'm
in
communities,
I'm
gonna,
go
get
this
information
up
and
skate
and
get
a
vault
open
and
make
it
available
to
the
application.
F
It
will
generate
a
token
with
appropriate
policies
for
the
job
or
for
the
myth
of
Haagen
communities
terms
and
make
that
available
and
actually
basically
render
it
through
some
templating
stuff
and
actually
sort
of
like
get
secrets,
ready
and
dropped
onto
disk
for
a
ram
disk
for
consumption.
And
so
you
know
that's
kind
of
the
the
full-on
integration.
F
There
are
different
kind
of
stages
that
doesn't
have
to
be
the
only
way
that
happens,
but
I
think
the
nice
thing
about
kubernetes
sort
of
doing
that
are
having
this
better,
better
granularity
and
then
associating
a
vault
token.
With
with
a
pod,
whether
that's
transparent
to
the
application
or
not,
is
that
some
of
our
customers
that
are
going
to
be
using
vault
enterprise
I
can
take
advantage
of
enterprise
features
that
offer
things
like
name
spacing,
so
that
kind
of
like
sandbox
vaults.
F
So
if
you
want
to
have
different
goodies
clusters
that
have
each
cluster
have
its
own
main
space
within
vault,
so
that
data
can't
leak
between
them.
That's
the
thing
possible.
You
know
if
you
want
to
have
kind
of
disparate
keys
that
are
encrypting
different
secrets,
so
you
can
ensure
that
only
some.
You
know
that
that
a
user
that
gets
access
to
one
key
to
revolt
policy
can
solely
read
a
subset
of
Secrets.
That's
another
thing
that
can
happen
so,
like
I,
think
there
are
a
lot
of
really
cool.
F
C
I
just
take
a
step
back
some
of
the
changes
that
we've
made
there
they're
a
couple
user
right
now
would
have.
They
can
optionally
absolutely
do
application
layer,
C
secrets,
encryption
using
ASUC,
mas
CBC
or
the
secret
box
provider.
They
can
also
optionally
use
a
kms
plugin.
There
are
canvas
plug-ins
for
Google
Cloud
cameras
as
your
key
fault,
a
wkms
and
there's
one
truly
being
released
for
hash
cord
fault
and
then
additionally,
for
vault
and
I
apologize
for
not
including
up
here.
You
can
have
pods
authenticate
directly
to
vaults,
using
corn
a
service
accounts.
C
F
F
C
C
One
is
that
we
somehow
have
a
way
to
externally
mount
your
import
secrets.
So
what
I
mean
by
that
is
I'm,
seeing
a
pattern
where
customers
have
a
secret
store
that
looks
somewhere
else.
It
may
be
vaulted,
maybe
a
custom
on-prem
thing:
it
may
be
a
secret
manager
like
aw,
a
secret
manager,
and
they
want
to
batch
import
these
into
inter
communities
on
a
regular
basis
so
stuff
having
a
way
of
importing
these
new
communities
and
having
communities.
Call
back
and
say:
has
this
thing
changed?
Let
me
update
it
that
that's
that's
one.
C
One
piece
that
I'm
proposing
the
second
piece
that
I'm
proposing
is
something
similar
to
sort
of
what
Jeff
was
started
to
talk
about,
which
was
having
some
sort
of
direct
mapping
between
namespaces
and
and
like
file
paths
and
other
services
I'm
an
easy
way
to
please
a
place.
To
start
this
would
be
with
faults,
but
it
doesn't
have
to
be
exclusively
the
third
major
change
that
I'd
be
proposing
is
improving
the
default
behavior
for
encryption
of
secrets
in
kubernetes.
C
So
what
I
mean
by
that
is,
since
1/7
users
have
options,
and
since
one's
tenth
one
time
they
have
a
kms
plugin,
but
by
default
secrets
are
still
not
encrypted
at
rest.
That
seems
like
a
major
mess,
so
I
don't
have
an
exact
solution
here,
but
moving
something
in
that
direction,
where
we
don't
provide
sort
of
a
false
sense
of
identity
by
using
a
local,
a
local
encryption
key,
but
pushing
towards
having
having
stronger
security
around
that
encryption
would
be,
would
be
what
I'm
proposing.
F
F
C
A
F
A
F
A
One
of
the
one
of
the
reasons
that
we
actually
can't
default
this
on
is
because
there
is
per
deployment
management
of
the
encryption
keys.
All
right,
so
kubernetes
is
an
ecosystem
of
a
bunch
of
different
artifacts,
and
so
the
the
API
server
binary
may
support
this
option,
but
it
is
only
one
binary
in
potential
eh,
a
cluster
managed
by
things
outside
of
itself,
and
so
I
mean
this
is
not
uncommon.
We've
seen
this
for
most
of
the
features
that
we've
worked
on
right.
A
A
B
The
main
interaction
between
secrets
and
pods
is
the
secret
projection
volume.
I
would
be
interested
in
seeing
somebody.
B
D
Yeah
I
feel
like
for
a
bunch
of
these
things,
including
importing
into
the
API
and
defining
those
all
feel
like
things
that
can
be
done
through
our
plugin
points.
Right
now,
and
perhaps
a
good
way
forward
is
to
sort
of
start
by
building
those
for
a
specific
key
store
solution
like
vault
and
then
from
there.
We
might
be
able
to
sort
of
extract
some
standards
or
say
like
here's,
the
best
practices
or
here's
a
reference
implementation.
D
A
Yeah
for
the
two,
the
two
ways
that
you
can
mount
things
into
pods
right
now:
there's
flex
volumes
and
CSI
flex
volumes
are
the
only
ones
that
are
supported
for
inline
pods.
So
if
you
had
a
pod
spec
that
included
a
flex
volume,
CSI
doesn't
support
that
yeah
that
just
links
to
a
proposal
that
is
talking
about
how
to
add
CSI
support
into
pod
specs.
A
That
would
one
of
those
mechanisms
is
likely
to
be
the
way
we
would
allow
injecting
content
directly
into
pods,
and
that
the
benefit
of
that
is
that
the
unencrypted
content
never
passes
through
the
API
server
to
cubelet
chain,
like
it's
point-to-point
from
the
the
thing
on
the
cubelet
that
is
talking
to
this
secret
source
to
into
the
container,
as
far
as
like
sinking
secrets
into
the
Kuban
IDs
api.
That
could
certainly
be
interesting.
A
C
A
I
think
if
we
have
multiple
implementations
and
it
would
be
good
to
get
feedback
from
those,
but
I
haven't
heard
a
lot
of
feedback
either
positive
or
negative.
But
if
we
are
able
to
solicit
feedback
from
the
people
who
have
actually
built
them
and
we
have
implementations
against
several
varieties
of
providers,
then
I
would
anticipate
that
could
be
promoted.
B
F
My
understanding
of
the
Oracle,
the
Oracle
built
volcanus
providers
that
they
submitted
as
PR.
It
was
closed
because
they
were
told
that
it
would
have
to
go
over
GRDC
and
they've.
Actually
they
have
a
fork
in
which
they've
built
and
merged
it.
Now
there
yeah
the
one
right
there
Oracle
number
four
right
about
that.
F
Don't
know
I
I
was
hoping
that
something
that
would
actually
know
more
about
the
status
of
it
then
than
me
since
they
said
yeah
we're
gonna
have
have
something
like
this
I
mean.
Maybe
they
plan
to
take
this
rapping
to
G
RPC
and
then
submit
that
that
might
be
what
what
KK
was
talking
about
in
the
in
the
other
issue.
The
standalone
version.
B
B
Don't
personally
know
the
current
status
I,
just
remember
that
we
were
looking
for
ownership
for
the
actual
plug-in
mechanism.
I
think
that
all
the
individual
integrations
had
had
owners,
but
the
reason
that
these
things
sometimes
flounders.
Somebody
works
on
a
feature
for
a
quarter
two
and
it
goes
slow
and
they
move
on
to
other
things.
So
it'd
be
good
to
have
somebody
step
up
and
own
that
feature
and
move
it
to
completion.
B
B
F
F
B
F
F
So
the
way
that
we
sort
of
envision
that
working
is
that
it
essentially
developing
a
container
that
can
be
used
as
either
in
a
NIC
container
a
sidecar
boat
depending
on
the
mode
in
which
it's
run.
So
you
know
in
a
container,
can
kind
of
provide
a
token
and
drop
somewhere
in
a
file
system
or
if
you
want
to
run
as
a
sidecar
to
kind
of
continually
grab
new
tokens
or
or
bundle
it
with
a
our
program
console
template
which
basically
templates
out
secrets
onto
a
data
source
somewhere.
F
Then
that
would
be
that's
something
that
we're
looking
at
so
I.
Think
that
that's
something
that
we're
gonna
provide
at
some
point,
I
think
I,
haven't
really
I,
haven't
really
heard
a
CSI
before
this
I
think
that
that
looks
like
a
really
interesting
way,
potentially
to
provide
this.
This
functionality,
so,
rather
than
us
sort
of
write
out
stuff
onto
a
template.
B
F
So
this
is
very
much
I
mean
I.
The
reason
I
don't
want
to
commit
to
work
right
now
is
because
we
just
we've
sort
of
been
looking
at
this
road
map
and
other
things
that
are
out
there
in
the
community
between
committee
doesn't
fault.
For
instance,
one
of
the
community
has
proposed
a
proposed
and
coded
a
community
secrets
plugin
for
vault,
so
that
Paul
can
generate
account
credit
tools
and
so
on
for
communities.
So
we
had
a
lot
of
things
for
trying
to
juggle
right.
F
E
C
The
doctor,
who
was
just
that
was
discussed,
please
review
uncomment
the
top
level
proposals
are
some
way
of
externally,
storing
our
mounting
secrets,
some
sort
of
external
store
off
integration
piece
and
having
a
better
default.
None
of
these
are
committed
they're,
all
just
under
discussion
and
separately.
Specifically
the
communities
plug-in.
It
sounds
like
we're
looking
for
an
owner
in
order
to
take
that
to
beta
in
the
next
few
releases.
Is
that
right.
C
F
A
F
C
F
Severe
lack
of
capacity
and
kind
of
a
big
crunch
right
now
in
terms
of
manpower
we
are,
we
are
hiring
more
people,
as
I
said,
so
that
will
hopefully
help
alleviate
that.
So
we
just
have
a
spirit
capacity
problem
right
now,
and
so,
since
it's
in
alpha,
we
were,
we
were
planning
on
waiting
until
it's
not
in
alpha
actually
implemented,
but
it
is
definitely
on
our
radar.
We
are
going
to
support
it.
Yeah.
A
F
B
The
current
credential
backend
works
by
sending
the
service
cut
token,
that's
the
secret
projection
to
the
vault
and
then
vault
does
the
token
review.
So
all
we
have
to
do
is
use
a
audience.
Pound
shot
and
vault
has
to
submit
its
expected
audience
and
I
think
it
should
be
a
very
small
change
on
vault
side
since
they're
already,
basically
there,
okay.
F
Yeah
I,
don't
think
we
have
looked
at
like
exactly
what
I
I'd
seem
that
the
proposal
I
start
getting
a
bit
for
like
the
proposal,
but
I
didn't
I,
didn't
fully
grok
the
exact
changes
coming
from
the
community
side.
If
it's
really
just
like
parsing
a
jot
man,
send
me
something
back.
That's
totally
simple:
I
figured
I
figured
from
the
scope
service
code.
F
F
F
B
B
F
Okay,
cool
yeah-
that's
that's
good!
No
I
should
continue
to
do
that.
The
reason
I
was
asking
is
in
in
cearĂ¡
10
4,
which
is
the
next
release
of
all
we're
gonna,
have
a
kind
of
a
generic
shot
and
OID
cos
I'm,
and
so
what
I
was
what
I
was
wondering
is
like
if
it's
basically
now
just
using
more
of
the
jot
stuff
than
we
might
just
need.
F
F
Okay,
yeah
no
problem,
but
we'll
keep
it
alive.
That's
actually,
to
be
perfectly
honest,
that's
been
happening
with
a
lot
of
a
lot
of
our
providers.
We
have
a
lot
of
things,
a
lot
of
plugins
now
that
basically
consume
shots,
but
then
call
kind
of
custom
API
to
do
extra
validation,
just
because
it
makes
sense.
So
this,
what
we're
introducing
is
basically
a
plug-in
for
the
rest
of
the
cases
that
don't
mean
a
custom,
a
custom
API
to
call
back
into
yep,
but
yeah
cool.
F
A
So,
just
to
go
back
up
to
the
top
of
the
the
112
list,
the
the
first
item
there
all
of
the
work
around
secrets.
It
has
actually
been
done,
but
that
was
done
back
in
1:7
I.
Think
there
is
one
item
left
around
nodes
not
being
able
to
label
themselves.
So
that's
not
a
secret
specific.
So
that's
that's
fine!
Right
now
a
node
cannot
list
all
secrets.
They
can
only
get
the
secrets
related
to
the
workloads
scheduled
on
them
and
that's
been
true
since
one
seven
four
deployments
that
use
the
node
restriction
and
node
authorizer.
A
Our
back
will
actually
let
you
authorize
individual
secrets,
it's
more
a
question
of
whether
the
controller
accessing
those
secrets
is
willing
to
fetch
individual
secrets
or,
if
it
kind
of
goes,
the
easy
yeah.
Let
me
listen,
watch
everything
and
keep
a
local
store,
which
is
what
most
controllers
do,
but
they
don't
have
to,
and
evidence
of
that
is
the
cubelet
right.
The
the
cubelet
doesn't
list
watch
all
secrets.
It
watches
the
secrets
related
just
to
its
own
workloads.
So
it's
already
possible
to
do
this.
It's
not
trivial,
but
I.
A
I
will
note
that
one
change
that
happened
in
111
is
that
when
you
watch
an
individual
secret
that
then
that
secret
is
available
to
the
authorizer,
and
so
previously,
if
you
watched,
even
if
you
watched
individual
secret,
you
would
still
have
to
be
authorized
to
watch
all
secrets,
but
as
of
111,
you
can
watch
an
individual
secret
and
just
be
authorized
to
watch
without
one.
So
that
is
a
new
capability
in
111.
That
I
know
that
the
responsiveness
issue
was
was
an
issue
for
some
controllers.