►
From YouTube: Kubernetes SIG Auth Meeting 20161214
Description
Kubernetes SIG Auth PUBLIC and RECORDED video meetings
Agenda: Automatic service serving cert signer controller; Vault integration demo.
https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/edit?ts=570fa5c5#
A
A
An
open
shift
Oh
as
far
as
recording
goes
I'm
reasonably
sure
that
this
reports,
the
entire
meeting
everyone
who
speaks
not
just
like,
then
the
other
thing
on
the
agenda
is
the
vault
controller
bit
Eric
tune
Ford
vet
I,
don't
see
him
here,
I'm
going
to
go
ahead
and
move
it
out
the
agenda
unless
until
he
is
able
to
to
work
it
out
because
I
don't
see
Kelsey
here
this
time,
do
that
so
the
service
serving
search
liner.
You
see
if
I
can
share
just
peace
along.
A
And
that's
broke
well.
Clearly:
I
am
NOT
a
skilled
as
Jordan.
Are
you
trying
to
share
escape
yeah
I'm,
trying
to
share
the
one
application
that
I
want
and
known
of
the
chrome
ones
are
labeled
all
right?
Well,
none
of
these
are
pornographic,
but
there
are
some
code
reviews
on
it.
What
do
you
guys
think
right
now,
I'm.
B
A
C
A
That
you
can
use
to
answer
requests
so
that
when
someone
relies
upon
your
service,
they
can
confirm
that
they
are
talking
to
you.
It's
important
that
you
end
up
with
a
serving
cert
that
can
be
trusted,
so
it
has
to
be
signed
by
someone
in
authority
and
an
individual
author
is
not
going
to
be
trusted
with
those
keys,
you
could
go
through
a
certificate
signing
request
process
where
you
actually
create
your
certificate.
You
send
it
off
to
be
signed.
You
get
defined
version
back,
use
that
you
embedded
inside.
A
If
you
were
your
namespace,
you
use
it
mountains,
but
if
your
pod,
you
won
that
procedure
works,
but
it
would
be
platform
itself
own
DNS
and
the
platform
itself
controls
controls,
traffic
routing.
Then
the
platform
can
also
inject
a
trust
certificate
for
you
and
a
serving
certificate
that
it
has
signs
that
only
you
can
use
and
get
traffic
brava
to
you
for
it.
It
removes
all
that
complexity
for
you,
you
have
you
create
your
service,
you
annotate
the
service.
A
Saying,
oh,
please
create
me
a
certificate,
and
then
your
template
makes
use
of
it,
and
let
me
find
the
example
that
I
had
of
actually
doing
this
in
poker
chips.
It
is
as
easy
as
annotating,
your
aha
as
annotating
your
service
and
then
the
pub
you
create
simply
depend
on
a
secret
and
because
the
way
scheduling
works,
your
pod
won't
be
scheduled
until
secret
exist,
and
so
you
get
launched
and
you
are
able
to
serve
with
your
surfing
surf
and
then
we
inject
the
trust
certificate
into
the
service
account
secret.
It
gets
automatically
know.
A
B
Mean
that
sounds
pretty
reasonable,
particularly
since
yeah
I
I
seem
to
so
it's
just
adding
another
secret
to
the
service
account
that
happens
to
be
a
server
certificate.
I'll
say
maybe
another
day
that
establishes
trust
with
other
things
signed
by
that
right
and
then
it's
just
at
a
well
known
location,
so
you
can
have
it.
Is
that
the
good
is
that
a
summary
of
the
it.
A
A
Is
right,
bigger
phone,
it's
right
here.
So
what
this
does
right
here
is
it
create
a
fun.
Config
is
roughly
analogous
to
a
deployment
for
engine
X.
It
creates
a
service
for
engine
on
the
explode
one.
It
annotates
that
service
with
the
annotation
that
says,
makes
me
a
service
surfing
search.
Then
it
mounts.
The
volume
attaches
it
to
the
deployment
and.
A
Then
it
says,
hey
actually
use
that
that's
what
this
config
Matt
does
and
then
it
waits
until
that
came
up
and
then
once
it
runs.
That
means
that
the
secret
got
created
and
then
we
can
actually
test
from
within
where
we
are
a
of
curl
and
somewhere
on.
The
script
would
actually
proof
that
it
works,
but
this
stuff
this
step
right
here
is
all
you
have
to
do
to
be
able
to
get
here
serving
sir,
and
it
is
an
extremely
powerful
and
useful
feature.
A
There
are
a
couple
pieces
which
I
guess
I
can
actually
pull
those
lines
up.
Some
of
the
notes
are,
there
are
a
couple
pieces
that
I
think
are
unique
to
open
shift
and
the
open
ship
router
that
make
it
easier
to
do
in
a
way
that
aren't
the
same
increment.
So
one
thing
that
we
have
with
our
router
is:
we
have
a
read
encrypt
move
the
router,
so
FFL
terminate
one
at
the
router
and
then
from
there
the
router
will
rien
crypt
and
make
a
connection
to
your
service
separately.
A
B
Don't
know
for
sure,
but
I'm
happy
that
TLS
from
it
that
ingress
controllers
only
do
TLS
termination
right
now
they
do
not.
That
is,
is
possibly
on
the
road
map
to
do
bright
kitchen,
but
it
is
not
a
feature
today.
I
think
you
can
do
I
I,
believe
you,
you
can
do
with
ingress
like
lower
layer
forwarding,
but
ok.
A
A
Exit
a
service
accounts,
token
secret
and
changing
that
service
accounts.
Open
secret
is
unusual,
but
I
think
that
if
you
wanted
to
do
it
in
fed
up
cadet
ease,
we
would
be
able
to.
It
will
have
interactions
with
people's
preferences
about
auto
mountain
or
not
automatic,
right
yeah,
and
that's
what
I
want
to
audit
mouth
public,
but
not
private
information.
A
A
A
C
A
C
A
Being
able
to
trust
a
a
different
see,
a
bundle
isn't
unusual.
A
cluster
admin
could
also
make
the
choice
and
say
we
recommend
you
start
from
this
particular
base
image
when
you
build
your
containers
on
top
and
that
base
image
includes
the
ca.
I
was
not
prepared
when
we
created
this
feature
to
say
that
this
should
be
injected
in
the
system
trusted
certificates
for
all
containers
without
their
permission.
C
A
C
A
A
We
saw
this
as
I
communicate
from
service
of
service
using
this,
but
by
the
time
I
terminate
at
a
client
I
am
being
served
by
a
route
and
sea
route
that
serves
me
is
signed
with
a
truly
official
da
right,
so
I
find
ebay.com
with
my
official
search
and
it
happens
to
come
in,
go
through
a
rien
critical,
my
pod,
to
have
that
particular
certificate
available
to
it.
Pay
for
pod
get
compromised
for
something
goes
wrong
in
that
namespace,
and
so,
when
you
down
to
that
level,
we
have
a
almost
throw
away
sign.
A
The
internet,
and
that
was
why
we
only
find
for
internal
name.
We
can
GERD
heat
on
the
platform
that,
if
we
sign
for
only
internal
keys,
that
should
only
be
routable
inside
of
the
cluster
from
one
part
to
another
that
we
have
time
something
valid
and
that
no
one
can
reuse
it
right.
If,
if
Eric's
field,
David
fine,
you
didn't
get
a
key
pair,
but
he's
in
a
different
project.
A
B
A
Are
served
inter-service
new
faces
now,
right,
as
we
add
extension,
API
servers
or
third-party
API
servers
that
ship
with
community
the
work
done
an
API
machinery
to
allow.
That
presupposes
that
you
are
going
to
be
running
these
additional
API
servers
inside
the
cluster.
They
are
going
to
ask
you
back
some
kind
of
storage.
A
There
is
benefit
to
saying
that
the
storage
is
exiting,
but
it
is
an
ftp
them
in
your
namespace
is
not
an
STD
sharing,
something
else
so
that
you
know
you
can't
have
an
extension
API
server
that
is
dominating
right
to
your
core
HD
and
in
those
cases
you
end
up
wanting
to
have
serving
certificates
for
SED
and
trust
inside
of
the
API
server
that
then
I
hit
it
just
last
week,
so
there
would
be
some
utility
there.
Yeah.
A
B
A
B
Yeah
it's
hard
for
me
to
say:
cuz
I,
don't
have
enough
expertise
on
basically
public
key
infrastructure
is
to
say
that
this
is
the
absolute
correct
way
of
doing
it.
I
definitely
see
the
value
in
trying
to
encrypt
more
traffic
inside
the
clustered,
but
I
might.
If
I
don't
know.
If
I
personally
can
endorse
it
as
one
way
that
we
should
go
sure.
D
This
sounds
pretty
cool
for
us
tonight:
I
deal
with
health
care
and
patient
data
a
lot
so
for
us
everything
has
to
be.
You
know
TLS
inside
the
cluster
and
out-
and
you
know
a
lot
of
times.
We
just
generate
self-censor,
it's
all
over
the
place
to
to
you
know
to
ensure
that
inclusion
there,
but
yeah.
It
sounds
helpful
to
help.
You
know
speed
us
up
with
that,
because
we
have
you
know
million
a
million
cell
science
or
sitting
around
in
different
places,
and
usually
we
own
the
minimum
secrets.
A
A
A
Unhealthy
kill
me
means
that
you
are
unlikely
to
bring
down
all
of
your
paws
at
the
same
time,
because
that
also
has
negative
repercussions,
but
one
pot
at
a
time
will
will
shoot
its
oakland
ahead
and
restart,
and
it
picks
up
the
nice
trick.
I
think
that
that
would
be
a
problem
that
I
would
want
to
solve
before
we
took
it
too.
C
A
A
E
Those
yeah
sorry
to
interrupt
it
sounds
like
a
good
conversation
was
kicking
off
there
and
I
think
my
demo
is
kind
of
in
the
same
vein
and
I'm
just
going
to
kind
of
show
a
prototype
that
has
been
working
for
some
customers
already,
but
we
can
do
much
better.
So
this
is
really
more
of
the
shoulder
prototype.
Kick
off
the
ideas
and
open
it
up
for
discussion.
I'm
going
to
share
my
screen.
E
Well,
can
I
ask
you
my
entire
desktop
all
right,
so
I'm
taking
you
guys
to
see
my
screen,
this
github
page
here,
yep
all
right,
great,
so
I'm
just
going
to
show
this
voltage
there's
a
couple
of
packs
too
I'm
doing
this
without
modifying
Cooper
Nettie.
So
there
are
much
better
ways
of
doing
this,
but
the
goal
here
was
to
give
something:
people
could
try
in
any
cluster
without
modification.
Ok,
so
one
of
the
things
that
a
lot
of
people
want
or
criticize
couperin
84
is
not
having
real
secret
and
I
understand.
E
Where
I
have
empathy
for
them
right,
they
like
vault,
they
like
the
way
vault
is
marketed.
They
like
the
way
it's
pitched
and
it
seems
to
solve
a
problem
when
they
don't
necessarily
have
all
the
things
you
would
find
in
a
cloud
provider
such
as
encryption
at
rest,
those
kind
of
things
so
Walt
coming
a
leading
solution
in
the
open
source
space.
I
would
say
that
has
a
lot
of
monster
around
being
focused
on
secrets.
E
So
what
some
people
want
is
for
each
pod
instance,
though
not
a
shared
key,
but
one
per
pod,
a
stanchion
to
have
its
own
unique
token,
that's
tied
to
the
identity
of
the
pod
itself
right,
so
you
can
imagine
you
would
have
tons
of
these
and
they
need
to
be
garbage
collected
which
would
be
handled
by
something
light
bulb
once
you
have
one
of
these
unique
token.
One
thing
people
like
about
volt
is
the
ability
to
do
dynamic
secrets,
so
both
has
all
those
backends
PKD
I,
my
sea
coral
dress,
even
amazon
a.
E
I
am
rolls
right.
So
if
you
want,
you
can
actually
read
from
a
path
and
a
dynamic
secret
will
be
generated
for
you
and
we'll
have
a
short
TTL
which
will
expire
or
could
be
renewed
all
right.
So
maybe
most
of
you
have
know
how
vault
works,
but
that's
a
high
level
description,
though
the
way
this
works
is.
We
need
a
way
to
give
each
pod
a
token
at
runtime.
E
Now
one
way
would
be
to
use
an
emission
controller
and
kind
of
rewrite
the
pod
to
inject
a
volume
or
secret
at
runtime,
but
that
requires
modifications
today,
I'm
criminais,
so
we
can't
do
that.
The
other
way
would
be
to
have
a
cool
it.
Do
it
right
the
Kubek
could
look
at
any
secret
type.
New
volume
tight.
This
whole
flow
had
inject
a
pod
and
keep
the
token
renewed
again.
E
A
few
modifications
required
they're
sort
of
warm
as
he
was
in
a
container
and
it
contained
knocks
on
the
door,
the
vault
controller,
the
what
controller
can't
trust
this
particular
pod.
We
don't
know
if
it's
a
real
pot
or
not
so
what
we
do
is
go
to
the
curb
Renee's
API
and
we
look
up
a
pod
with
that
name.
If
we
find
a
pod
with
that
name.
We
also
look
for
a
few
annotations.
E
You
know
volt
project,
IL
policies
and
given
that
we
will
then
create
a
token
what
we
call
a
rep
token
in
the
pot
and
a
board
so
to
only
be
unwrapped
once
for
its
target
and
then
the
real
token
will
be
underneath
there.
If
someone
beats
you
to
the
unwrapping
process,
you
can
raise
an
alarm
to
know
that
that
and
in
the
middle
has
taken
your
your
your
token
and
we
will
then
write
back
to
the
pod.
So
we
get
the
plot
IP
from
Cooper
Nettie's
and
we
write
back
to
the
pod
in
it
container.
E
So
then
it
containers
up
and
running
it's
listening
on
a
well-known
port
and
we
give
it
the
raft
token.
The
init
containers
job
is
to
unwrap
the
token
by
talking
to
a
wall
in
step,
5
and
in
step
6.
The
init
container
can
write
the
choke
into
a
shared
path,
I
shared
volume,
and
that
will
allow
the
container
to
come
up
and
read
the
token
to
grab
further
secrets
right.
So
what
I'm
going
to
do
is
kind
of
just
show
this
in
action
and
then.
E
A
E
About
Who
I
am
you
can
lie
it?
You
can
lie
all
you
want.
You
can
say
that
your
pod
fubar,
you
can
lie.
You
can
do
whatever
you
want,
you
can
be
malicious
and
all
we're
going
to
do
is
go
to
the
crew
bearnaise
18yo
disregard
who
you
said
you
I
mean
we're
going
to
take
advisory,
name
that
you've.
Given
us.
If
we
find
that
pod
by
name
in
the
KU
béarnaise
API,
we
have
to
trust
ackerman
shi,
no
way
around
it.
A
A
E
That's
right,
okay,
and
once
you
do
it,
though
so
the
thing
about
this
whole
rack
token
thing
that
the
hazard
cook
team
has
they
expect
that
useless.
They
expect
you
to
man
in
the
middle
and
unwrap
the
token
once
you
unwrap
the
token,
the
men
in
the
middle
at
step,
for
that
five
will
fail,
because
the
chokin
has
already
been
unwrapped
and
vote
will
raise
an
alarm
and
say
hey.
This
is
trying
to
be
unwrapped
twice
so.
E
Doesn't
matter
if,
if
you
wait
too
long
and
step
five
beats
you
then,
when
you
go
to
unwrap
step,
for
the
thing
you
have
is
garbage,
the
real
token
is
behind
the
rap
token
in
volt,
so
only
well
can
respond.
What
the
actual
token
that
you
need
to
use
going
forward.
So
this
is
a
one-time
use.
Token
we're
passing
on
step.
Four.
F
But
a
man-in-the-middle
can
intercept
the
rap
token
and
then
use
it
to
unwrap
if
in
a
race
condition
situation
absolutely,
but
it's
dip,
but
it's
detectable.
That's
that's
the
key
right.
If
the.
If
the
real
application
doesn't
get
the
token
because
the
rapper
has
already
been
used,
it
then
that'll
raise
a
red
flag
and
you
should
be
able
to
use
the
audit
log
to
find
out
what
happened.
That's.
E
Right,
that's
the
goal
of
this,
it's
not
to
prevent,
but
it's
at
least
to
be
able
to
identify
quickly
that
it
happened.
Okay,
all
right,
good
question
by
the
way,
so
now
I'm,
just
gonna
walk
you
guys
really
quickly
through
this.
I
have
this
tutorial
online
she'd
also
follow
through
like
any
cluster
openshift.
It
doesn't
matter.
You
know
here,
I'm
just
going
to
download
this
controller,
all
right
I'll,
just
set
up
and
we're
just
going
to
deploy
it
really
quick.
E
B
E
Yeah
I
have
my
terminal
and
I'm
just
going
to
create
a
namespace,
so
we
don't
jump
up
the
place
here,
I'm
just
going
to
now
deploy
waltz
and
devil.
So
there
are
better
ways
of
deploying
bolt
that
we're
not
going
to
waste
time
with
that,
I'm
just
going
to
say:
hey,
stand
up
in
dev
mode
and
use
this
route
key,
so
we
can
actually
go
on
with
this
demo
pretty
fast,
but
it
is
a
standard
wall
container
that
I'm
getting
from
the
Gotham
hub,
managed
by
the
hash
you
Corky
at
this
point.
E
You
should
have
vault
running
inside
of
our
cluster,
so
there
we
go.
We
have
vault.
The
next
thing
I'm
going
to
do
here
is
really
quickly
create
a
secret
for
volt,
oh
I
service.
Now
this
just
tells
us
that
we
can
now
reach
vault
over
a
standard,
DNS
name
common,
coronary
stuff
here,
and
this
is
the
key
that
we've
pre-populated
with
in
dev
mode.
So
that
way
we
can
easily
start
to
manage
this
bolt
cluster
to
configure
it
ok
now.
E
The
second
part
is
this:
is
a
custom
component
here,
the
controller,
a
very
small
shim,
to
execute
that
flow.
We
saw
early
in
the
diagram
and
we're
just
going
to
create
a
secret
for
so
I
can
access
bolt
using
the
master
secret.
So
it's
going
to,
we
could
try
to
lower
privilege
token
that
can
just
do
everything
on
happy
half
a
pods.
That's
up
to
you,
implementation
that
vault
does
have
that
where
we
can
create
tokens
that
have
lower
privilege
than
others.
Now
we're
just
going
to
deploy
this
controller.
E
Very
simple
controller
here
all
at
once
is
to
know
where
volt
is
and
what
token
to
use
and,
of
course,
we're
just
going
to
read
that
token
from
a
secret
and
make
sure
that
it's
mounted
as
an
environment
variable
and
we're
just
going
to
step
a
rep
TTL.
So
we
create
rep
tokens
on
behalf
of
pods.
It
all
works
so,
given
that
we're
just
going
to
run
the
controller
in
the
same
namespace
that
we'll
be
able
to
talk
to
bolt,
but
now
we
have
pretty
much
the
core
infrastructure
in
place.
E
So
now
we're
able
to
kind
of
use
this
new
service
in
Coober
Nettie's
once
this
actually
complete
scoop,
proxy
and
load
itself
or
spinning
it.
So
now
we're
good
core
infrastructure
is
in
place.
Now,
let's
create
a
service
for
the
wall,
controller,
so
pods
know
who
to
ask
or
knock
on
the
door
to
get
this
request
flow
going.
So
now
that
we
have
that,
we
now
have
the
two
bits
we
need
for
vault
in
this
now.
E
What
I'm
going
to
do
now
is
skip
to
this
use
case
of
short-lived
TTL
certs,
with
mutual
off
between
microservices,
so
welcome
to
customers
out
in
the
field.
Everyone
wants
to
do
things
with
network
policy.
It
all
gets
so
complex
and
an
alternative
would
be
less
use
short
TTL
certificates
in
this
case
on
this
demo,
the
only
last
for
one
minute
once
you
can
bump
that
higher,
if
you
want
the
goal
here,
is
that
we
will
make
explicit
use
of
multiple
pki
back
end,
so
one
CA
per
service.
E
E
So
the
first
thing
you
need
to
do
really
quick
is
we're
going
to
do
we're
going
to
configure
bolt
really
fast,
you
can
kind
of
see
the
developer,
workflow
would
be,
or
the
system
administrator
we're
going
to
get
a
reverse
tunnel
did
won't.
Let
me
into
my
cluster,
since
it's
not
exposed
publicly
now
I'm
going
to
hit
volts
from
the
client
zone
and
hit
the
boat
address.
Configure
the
token
to
my
local
client
on
my
laptop
and
hit
it
we're
going
to
make
sure
vote
is
running.
So
we
see
vote
is
up
and
running.
E
This
is
great.
Now,
let's
try
to
configure
it
really
quick,
so
I'm
going
to
go
pretty
fast.
I
want
to
mount
the
dynamic
backend
for
pti.
Then
you
can
mount
as
mini
PK
back
into
one
again
one
for
every
micro
servers.
If
your,
if
you
so
choose
once
you
have
this
PTA
mount
mount
it,
you
need
to
configure
it.
The
one
I
do
with
this
series
of
commands
here.
E
E
You
should
tell
today
all
right
so
now,
I'm
just
going
to
write
a
little
bit
more
configuration
for
votes
all
right,
so
now
we're
getting
close
so
now,
at
this
point,
we're
going
to
do
two
policies,
one
specifically
for
clients
only
and
one
for
servers
only
and
then
we're
going
to
allow
these
starts
to
be
generated
for
clustered
that
local
and
one
thing
that
we're
doing
is
we're
making
sure
that
we
do
have
the
clients
generate
these
certificates,
they're,
generating
them
to
be
trusted
by
every
possible
communication
mechanism.
That
includes
the
plot
IP
localhost.
E
E
E
What
we're
doing
is
grabbing
the
IP
address
from
at
the
clients
based
on
what
has
been
configured
with
right.
So
if
there's
conflicts
on
the
same
system
or
in
different
systems,
I
am
not
detecting
that
it's
a
second
or
two
I'll
have
other
issues,
but
you
will
be
able
to
have
an
IPO
just
a
trusted
by
everything,
that's
accessible
to
an
alt
and
won't
ok.
A
E
Networking
drowning
nope,
let
me
show
you
so
this
is
a
great
question
and
we'll
show
you
what
safeguards
we
put
in
place
for
this.
So
let's
create
this
server
role,
client
role,
server
role
so
right.
We
need
these
two
policies,
so
that
way,
so
remember
everything
is
based
on
policy.
So
while
you
may
be
able
to
spoof
the
IP
that
you
get
your
cert
sign,
for,
we
won't
be
able
to
generate
a
certificate
unless
you're
trusted
and
supposed
to
ok.
E
So
here
we're
going
to
write
this
policy,
so
this
policy
says
you
can
be
a
micro
service
and
you
will
have
the
ability
to
grab
a
client,
cert
or
a
server
sir,
but
you
need
a
token
created
with
this
policy
set
in
order
to
do
that,
not
everyone
can
grab
one
of
these
certs,
this
precious
policy
to
volt,
really
quick
right
policies
inside
a
vault.
Now
we're
ready
to
go
so
at
this
point
you
have
these
two
paths.
Now,
how
do
you
tell
a
pod
what
what
policies
is
allowed
right?
E
So
we'll
put
this
as
a
annotation
in
the
pot.
So
this
will
let
you,
as
the
administrators
say
that
you
get
the
default
policy
and
microservice.
The
vote.
Controller
will
generate
your
token
based
on
this
policy.
But
even
if
you
have
a
pas
de
has
one
IP
and
able
to
go
away
and
another
pot
comes
up
in
its
place
with
the
same
IP.
C
A
E
Pod
IP
that
I
balanço
do
right
and
here's
a
problem,
it's
so
short-lived
that
yeah,
if
you
can
convince
kerber
Nettie's
to
route
you
for
that
particular
service
right
to
that
IP
address.
So
you
went
in
there
and
you
got
added
to
the
service
backing.
You
have
all
the
same
pod
labels,
but
you
don't
have
the
annotations
to
get
your
own
certificate
here.
Even
if
you
get
a
volt
token.
Your
token
is
not
ballot
to
renew
that
certificate.
You
just
stole,
and
it's
going
to
expire
from
underneath
you
and
become
untrusted
by
everyone.
E
That's
just
a
common
with
kerber
Nettie's.
If
you
want
to
you,
can
create
all
the
policies
you
want,
so
you
can
use
our
back.
You
know
when
you
get
that
pod
definition
in
of
Z,
you
could
say
no
you're
not
allowed
to
create
pot
or
replication
setter
deployment
that
uses
these
policies
right.
That
would
have
to
be
enforced
higher
up
in
the
stack
around
just
overall.
Obviously,
what
can
people
push?
It's
like
referencing,
a
secret
or
stopping
someone
from
referencing
signal
to
benetti's
by
just
putting
a
a
secret
volume
in
place.
Well,
doesn't
that
question?
E
E
That's
the
true
pernetti's
model
right.
So
this
is
what
the
whole
you
know.
A
mission
controller
thing
is
about
right.
If
they
user
a
specific
user,
you
get
a
chance
to
inspect
the
object
that
they're
trying
to
create,
and
if
you
don't
want
a
specific
class
of
users,
creating
objects
that
have
references
to
specific
secrets,
then
your
job
at
the
of
Z
layer
would
be
to
look
at
the
request
and
deny
it
based
on
your
company
policy.
E
Soaker
bernetti
is
from
what
I'm
discussing
right
now
as
a
framework
for
doing
these
things
it
openshift
wanted
to
do
this
open
ship
could
have
provided
a
mission
controller
and
a
UI
to
let
a
user
do
this
right,
I've
seen
some
startups
with
their
own
policy
engines
that
do
this
today.
Have
these
custom
of
mission
controllers
maybe
compile
the
Trinities
binaries
and
now
the
user
can
now
say:
hey
use
this
a
mission
controller.
E
That's
a
problem
in
general
right,
so,
if
you
take
away
this
whole
meeting
right
now,
you
have
that
problem
anyway,
just
in
general
Coburn
any
shortcoming
in
terms
of
a
framework.
If
you
really
want
to
see
that
I
definitely
think
we
can
probably
create
a
whole
issue
around
what
the
default
implementation
for
all
Z
should
look
like
at
that
granularity
for
an
admission
controller,
but
until
then
most
people
are
using
to
pernetti's
and
what
they
do.
R
is
locked
down
who
can
access
and
create
these
these
objects?
E
E
Demo,
this
is
a
dimple.
We
want
to
make
sure
it's
easy,
because
if
you
want
to
use
and
I
have
a
different
repository
that
shows
you
how
to
run
a
production,
great
vault,
you
need
a
CA
first
or
certificate.
So
that
way
you
can
lock
down,
but
with
ups
you
can
provide
that
particular
seeker
to
all
the
places
that
they
trust
that
particular
import.
So
yep,
that's
will
prevent
some
deployments,
but
for
this
concept
this
idea
this
is
good
enough
to
communicate
the
flow,
but
totally
in
production,
lock
down
Rosen
all
right.
The
toes.
E
This
is
where
we
decide
what
we
want
to
do.
Well,
you
could
either
have
a
third-party
resource
where
user
could
say.
You
know
I
want
these
kind
of
tools
for
this
class
of
apps,
and
we
do
it
on
behalf
of
the
pot.
The
Cleveland
could
assume
this
role
or
the
app
itself
cannot
to
take
this
role.
So
today,
a
lot
of
people
know
ball.
Community
are
just
needed
to
connect,
sweet
and
I'll.
Take
care
of
this
themselves.
You're
right.
This
assumes
that
today
the
application
would
be
aware
that
could
be
an
edit
container.
E
All
right,
so,
once
we
have
this,
we
now
can
start
using
this
annotation
to
start
to
do
policy
and
again
we're
going
to
go
with
the
the
administrator
has
the
right
to
do
this
and
it's
lockdown
right.
But
this
is
a
great
observation
now.
What
we
want
to
do
now
is
have
our
apps
that
are
vault
aware,
how
do
they
request
their
certificates
and
again
this
is
a
future
that
we
could
provide
it.
We
wanted
a
generic.
E
You
know
plum
the
container
with
the
well-known
certificate
that
we
renew
ourselves
with
the
couplet
and
in
that
place,
what
I'm
doing
and
I
wrote
this
code.
So
we
can
see
what
we
would
do
in
the
cooler,
so
here
we're
going
to
get
the
pot
IP
because
since
we
know
it
will
also
take
localhost,
because
you
could
have
an
actor
inside
of
the
pot
wanting
to
talk
to
the
service
over
local
hosts,
but
over
HTTPS,
and
then
here's
all
the
DNS
names
from
our
spec
right.
E
E
So
once
we
have
those,
let's
just
take
a
look
at
the
server
implementation
and
I'm
just
going
to
show
you
guys
the
log,
so
you
can
kind
of
see
what's
happening
here
and
we're
almost
done.
Thank
you
for
your
patience
here.
What
we're
doing
is
this
is
kind
of
nasty,
but
it's
all
we
have
for
now.
We
have
this
annotation
here
so
I
want
the
default
in
micro
service
policy,
I'm,
also
giving
you
a
hint
of
the
TTL
that
I
want.
E
So
no
more
than
24
hours
is
the
max
TTL
for
the
token
and
then
here's
the
init
container.
So
this
is
a
little
helper
to
kind
of
demonstrate
the
idea
so
vault
in
it.
It's
job
is
to
go
to
that
work.
We
saw
in
the
diagram
it's
going
to
get
it
spot
name
from
the
downward
AP
I
applaud
namespace,
also
from
the
downward
API,
and
then
it's
just
going
to
ping.
Well,
we
need
to
talk
to
vote
on
step
five,
where
we
actually
unwrapped,
but
we
also
want
to
talk
to
the
world
controller.
E
So
here's
all
the
data
we
need
to
make
that
initial
request
to
start
the
flow.
Now.
This
app
will
also
listen
on
a
well-known
port
on
it
spot
AP.
So
that
way,
when
the
callback
happens,
we're
ready
to
go
and
then
we're
going
to
write
the
resulting
unwrapped
token
to
this
particular
path.
So
just
fall
in
a
very
similar
pattern.
We
do
for
service
accounts
and
you
notice
down
here
to
have
a
shared
volume
with
empty
der
just
to
ensure
that
when
this
pot
is
deleted,
the
secret
is
cleaned
up.
E
We
share
that
volume
amount
with
whatever
application
will
be
running
long
term
after
the
init
container
completes
all
right,
so
in
it
container
runs
it
will
execute
and
then
our
politics
over
and
again
this
is
just
client
information.
So
when
we
go
and
generate
our
certificate,
we
need
to
know
the
pot
I
pea,
pod
name
and
also
we
want
to
know
our
name
space
as
well.
Okay
and
then
we
also
need
to
know,
and
then
I
just
have
flatulence.
Oh,
this
is
this
code
that
shows
what
we
could
do
in
the
couplet.
E
If
we
wanted
to.
Let's
launch
this
server
really
fast,
so
we
can
actually
see
this
in
action.
The
server
code
is
being
deployed.
It's
going
through
this
in
it
flow
I'm,
going
to
create
a
server
service
object
for
so
you
can
add
it.
So
you
other
pods
can
communicate
well
look
at
the
logs
for
it
really
quick,
so
I'm
going
to
look
at
the
logs
for
the
vault
in
it
container.
E
Let's
make
sure
this
is
dulce.
We
just
want
to
look
at
the
vault
in
a
container.
So
here
you
see,
the
vault
in
it
container
tries
to
clean
up
to
make
sure
the
secret's
out
in
place.
It
talks
to
the
controller.
We
get
an
error
because
it's
not
my
IP
is
not
there
yet,
which
is
ok.
We
try
again
and
then
we
get
the
rat
token
from
this
ball
controller.
We
unwrap
it.
So
we
get
it.
We
wait
for
the
call
back
and
then
we
unwrap
the
token
and
excellence.
E
E
C
E
A
C
E
Let's
finish
this
use
case
and
I'm
going
to
show
you
now
and
now
out
your
thing,
so
we're
going
to
finish
this
up
really
quick,
so
we
have
our
server
with
a
unique
certs
renewing
in
the
background
doing
the
right
thing.
So
if
you
hijacked
a
cert
search,
it's
not
going
to
be
good
because
you
won't
be
able
to
renew
it.
That's
the
whole
point
of
these
short-lived
TTLs.
So
the
next
thing
we
want
to
do
is
start.
E
The
client
very
similar
code
is
set
for
its
going
to
request
a
client
certificate
using
a
different,
back-end
and
bolts,
and
then
you'll
see
a
very
similar
thing
that
happens
with
the
inner
controller.
So
we
won't
look
at
that,
but
once
the
init
controller
finishes,
you
know
it's
still
initializing
right
now
we
see
that
the
cert
itself,
the
client
grabs
its
own
certificate
and
starts
renewing
it
in
the
background.
E
So
now
it
has
a
certificate
trusted
by
the
server
and
you
can
see
it
creating
successfully
doing
a
TLS
handshake
and
get
in
response
from
the
server
that
we
trust
right.
Everything
is
in
to
invalidate
it,
and
now
we
kind
of
have
this
service,
though,
if
we
ought
to
scale
any
of
these
things
horizontally,
everything
will
go
to
this
flow
grab
its
own
unique
certificate,
short-lived
and
trust
it.
You
know
you
have
this
kind
of
real
ring
of
trust
using
the
Volt
pki
okay.
So
that's.
E
E
Renewing
these
apps
actually
know
how
to
deal
with
renewing
things,
so
they
understand
that
when
I
get
a
new
certificate,
how
to
serve
it
at
runtime,
you
know
go
mix
that
really
easy
because
replace
the
mme
representation
of
the
certificate
and
the
nextel
s
handshape
will
use
a
new
cert
to
handle
the
next
request.
So
that's
totally
smooth.
We
want
you
need
to
know
what
else
now.
The
last
question
you
had
was
about
generic
secrets
so.
A
E
So
depends
right,
so
I
actually
have
this
problem
as
well,
and
what
I
normally
do
in
my
apps
I,
actually
listen
to
kind
of
a
trusted:
HTTP
endpoint,
first
health
checks.
So
if
you
just
want
to
ping
them
just
respond
200,
if
I'm,
healthy
or
not
I
tend
to
this
rate
limit
that,
but
it's
not
https
and
I
may
make
it
only
internal
to
the
cluster.
So
I
expose
443,
but
I
don't
expose
the
HTTP
endpoint,
which
gives
you
access
to
the
routes
that
health,
gentle,
sorry.
A
E
I
mean
you're
right,
I
mean
a
lot
of
people
want
to
do
the
thing
where
they
have
a
bunch
of
administrators,
that
going
on
restarting
services
a
picnic
employees
and
that
issue
I.
Definitely
think
you
know
someone
has
to
solve.
Not
me,
you
know,
I
tell
people.
Look
you
want
to
take
advantage
of
this
time
in
the
world.
You
need
to
be
able
to
do
things.
Don't
long.
Look,
we
don't
want
to
write
code,
great,
find
someone
to
solve
the
problem
for
you.
E
C
E
B
Is
so
the
open
ship
proposal
earlier,
just
nothing
proposed
necessarily,
but
just
a
conversation
about
how
openshift
of
some
of
this
it
still
has
to
deal
with
the
idea
of
that
source
will
expire,
things
will
and
applications
won't
know
how
to
update
them.
In
the
same
way,
we
have
had
discussions
in
the
past
about
service
accounts
and
trying
to
do
rotation
around
service
account
credentials
beyond
just
tokens
and
I.
Think
that
a
lot
of
those
conversations
and
including
the
vault
thing
sort
of
go
into.
How
do
we
rotate
secrets
when
the
applications
are
aware?
F
I'd
send
us
we've
been
talking
about
the
Ambassador
pattern,
a
lot
where
we
delegate
this,
those
those
issues
to
a
reverse
proxy,
that
basically
decorates
the
request
with
authentication
information,
so
the
application
doesn't
have
to
be
aware
of
it,
and
then
the
the
decorator
or
a
master
app
is
then
responsible
for
working
with
volta
to
rotate
credentials.
It's.
F
Doesn't
the
app
thinks
it's
talking
to
the
to
the
the
reason?
It's
called
a
reverse
boxes,
because
the
application
doesn't
know
that
it's
not
using
proxy
protocol,
which
is
like
when
we
think
of
for
epoxy
or
taking
a
little
traditional
squid,
we're
basically
you're
requesting
a
resource
on
behalf
of
another
resource
explicitly,
but
for
the
reverse
proxy
you're.
Talking
to
the
Ambassador
is,
though,
where
the
the
foreign
server
and
it's
a
problem.
F
E
I
think
this
is
like
all
right
once
you
have
this
kind
of
mechanism
in
place.
You
got
choices,
you
can
just
take
the
token
go
to
town
yourself
or
we
could
do
more
help
for
the
user
and
say
hey
we're
going
to
plum
a
well
known
location
with
things
like
you
know,
key
value,
pair
secrets
and
and
certificates
and
your
choice.
You
can
consume
them
in
your
app
will
renew
or
if
you
don't
want
to
consume
your
app
and
you
don't
want
to
provide
like
a
hook.
E
Maybe
you
will
handle
a
specific
signal
that
we
can
send
to
any
generic
app.
You
handle
the
signal
which
tells
you
to
reload,
configs
or
or
cert
or
you're
right.
We
could
decide
that
we
have
these
sidecars,
but
in
the
pod
world,
that's
just
kind
of
the
users
choice
right.
How?
How
much
do
they
want
the
platform
to
do
for
them?
Yeah,
but
I
think
the
world
where
it
is.
F
E
But
the
Ambassador
itself
would
work
the
same
way
as
a
developer
that
did
decide
to
actually
confirm
those
secrets
right
and
responsible
for
impression:
meanest,
the
Ambassador
itself.
It
isn't
at
that
red
hat
or
I
chose
to
write
on
behalf
of
the
user,
but
it
doesn't
really
change
the
model.
It
just
says
the
user
can
use
a
prebuilt
application.
That
does
the
right
thing.
Yeah.
F
E
Yeah
out
of
the
boxing
and
undecorated
for
you
yep
out
of
the
box
all
day,
but
let's
not
miss
the
opportunity
to
let
people
level
up.
Who
would
just
like
to
do
this
in
their
own
code
base
that
thing
all
the
skills
and
oh,
absolutely
yep,
so
that
that's
pretty
much
it
so
right
now
there
are
people
using
this
pattern
actually
in
production.
Where
scares
me,
but
it's
a
very
simple
pattern.
E
People
just
want
to
talk
in
they've,
already
committed
to
vault
they're
happy
with
the
vault
API,
the
usable
in
other
places
outside
of
Coober
Nettie's,
and
this
solution
gives
them
the
ability
to
use
volt
in
more
places
and
decide
the
granularity
around
secrets
that
they
want.
So
now
the
conversation
is
you
lean.
The
KU
béarnaise
community
see
value
in
something
like
vault
outside
of
this
kind
of
initial
prototype,
simple
use
case
and
go
deeper,
I
think.
E
Well,
in
volts,
I'll
tell
you
in
volt,
that's
kind
of
the
initial
use
case,
volt
great
secret,
blah
right,
and
then
you
have
policies
that
can
read
various
secret
buckets
by
name
or
pattern,
so
they
work
flow
for
the
administrator
and
I
watch.
A
couple
of
companies
that
use
vault
heavily.
What
they
do
is
meant
active
management.
Managing
seekers
is
somewhat
decoupled
from
kuber
Nettie's
or
any
other
platform.
Dva
says
we're.
Changing
the
database
passwords
we're
putting
them
in
volt.
That's
it.
E
You
know
where
they
are
and
then
to
consume
those
it's
up
to
you
to
either
pull
them
out.
Meili,
puppet
or
chef
or
absolute
Michael,
totally
match
them
from
vult
to
cure
Burnett
ease
and
yeah
you're
right.
You
have
to
deal
with
the
reload
problem
when
they
change,
but
that's
kind
of
the
contract
that
bull
provides.
Hey,
take
place
to
store
them
an
API
to
get
them
out
audit
log
to
see
who's.
Looking
at
what
and
a
policy
mechanism
to
prevent
various
actors
from
accessing,
Orchestra
performing
for
so.
F
What
we're
doing
at
desk
is
a
we're
actually
doing
something
similar
with
a
similar
controller
to
the
the
certificate
controller.
You
created
that
populates,
an
Ian
veter
like
basically
an
inverter
with
the
secrets
that
a
particular
pod
is
authorized
to
access
and
then
cross
mounting
that
enter
into
the
into
the
consumer
pod
right.
E
So
many
use
cases
with
this,
but
I
think
what
I've
seen
the
community
be
happy
with.
Is
that
vault
itself,
as
a
standalone
tool,
is
very
well
focused
on
secrets
in
a
meaningful
way,
dynamic
and
generic
secrets
and
custom
back
ends?
If
you
want
to
do
a
new,
you
know
dynamic
secret
that
goes
out
to
the
CIA
and
configures
a
hardware
token.
That's
up
to
you.
That's
just
bolts
world.
A
E
So
this
is
what
I
was
just
showing
you
right.
So
in
this
demo
you
saw
a
glimpse
of
it.
You
can
expect
you
can
extend
it
more
right.
So
if
you
want
what
you're
asking
is
policy
here,
you
just
add
another
line
right,
you
would
say:
let's
say
you
have
some
database
secrets
right.
You
can
come
here,
create
a
new
line
in
this
policy
and
updated
at
runtime.
E
So
you
don't
even
have
to
change
the
app
and
just
say
secrets
and
then
foo
so
right
underneath
that
will
be
generic
secret
bucket,
like
we
have
in
Coober
Nettie's,
and
then
you
give
this
app
the
capabilities
to
read
from
it
right
list
them
delete
them.
Well,
we
may
not
want
to
let
them
delete
will
say
you
can
list
them.
We
don't
need
you
to
update
them.
E
E
This
is
all
in
the
vault
documentation
right,
so
it
could
be
my
sequel
and
then
it
would
be
like
accounts
or
something
and
this
guy
and
then
is
the
request
that
I
make
sure
this
another
thing
controlled
by
annotation
know
so
the
annotation
just
says:
what
policy
do
you
have
so
right
now
this
is
the
microservices
policy
we
have
so,
instead
of
you
trying
to
get
grayndler
everywhere
leaking
all
these,
you
want
to
keep
it
easy
for
the
user
right,
don't
want
the
user
doing
all
of
that
kind
of
thing.
So.
B
E
There
needs
to
be
intermediate
trusted
actor.
Well,
let
me
clarify
that
when
you
create
a
token
for
the
controller,
you
can
also
give
it
a
policy
that
is
also
limited
in
what
it
can
and
can't
do
right.
So
right
now
we're
using
the
root
token,
which
can
do
everything,
god
mode,
but
you
might
say
well.
This
is
walt,
and
I
only
want
this
controller
to
have
a
token
that
can
only
access.
Maybe
these
eight
policies
right.
E
So
when
it
goes
out
to
generate
a
token,
it
can
only
generate
these
toke
and
what
specific
policies
attached
to
them,
and
if
that
key
doesn't
have
that
level
of
privilege
or
permissions,
it
will
fail
in
its
generation
on
token
of
the
cash.
So
it's
almost
like
this
delegator
pattern.
It
needs
more
anything
love
our
permission
of
more
than
all
the
policies
you
would
like
to
have
it
generate
on
behalf
right.
So.