►
Description
Vault and Secret Management in Kubernetes [I] - Armon Dadgar, HashiCorp
Secret data is everywhere, from database credentials, TLS certificates, API tokens, to encryption keys. Manageing secrets is a difficult challenge, but HashiCorp Vault provides an answer. In this talk, we discuss the challenges in secret management, provide an overview of Vault, and discuss how Vault and Kubernetes can be integrated. Integrating Vault solves the basic secret management challenge of securely distributing credentials, but also gives applications running Kubernetes access to features like dynamic secrets which are generated on demand and cryptographic offload to securely manage data in transit and at rest.
About Armon Dadgar
Twitter Tweet LinkedIn Connect Websitehttps://hashicorp.com
Armon (@armon) has a passion for distributed systems and their application to real-world problems. He is a founder and CTO of HashiCorp, where he brings distributed systems into the world of DevOps tooling. He has worked on Nomad, Vault, Terraform, Consul, and Serf at HashiCorp, and maintains the Statsite and Bloomd OSS projects as well.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
So
for
those
of
you
who
don't
know
me,
my
name
is
Arman
Dodd
Kat
you'll
find
me
all
around
the
internet
as
just
ARMA
and
I'm,
one
of
the
co-founders
and
CTO
of
Hashi
Corp.
For
those
of
you
who
don't
know
about
Hoshi
Corp,
don't
worry,
it's
very
common
people
know
us
much
more
for
our
tool
names
than
they
know
the
company.
So
you
know
it's
part
of
our
regular
education
campaign
that
there
is
also
a
company
behind
it.
Most
folks
are
probably
familiar
with
our
vagrant
tool,
maybe
terraform.
A
We
make
a
handful
of
different
tools,
but
really
our
overarching
mission
is
looking
at
the
challenges
around
delivering
an
application,
whether
you're,
an
IT
operator
trying
to
figure
out
how
to
provision
and
manage
infrastructure,
whether
you're,
a
security
engineer
trying
to
figure
out
how
do
we
deal
with
this
brave
new
world
of
cloud
and
zero
trust
networks
or
whether
you're
application
developer?
Who
just
wants
a
runtime
platform
and
want
to
find
your
upstream
services
and
don't
really
care
about
the
bits
and
bytes
and
how
they
all
connect
together?
A
And
so
because
we
try
and
look
at
so
many
different
problems.
We
have
quite
a
different
handful
of
tools,
so
not
kind
of
spend
a
lot
of
time
talking
about.
Most
of
them
instead
want
to
specifically
spend
time
today
on
vault
and
the
security
challenges
we
face
as
we
go
to
the
cloud
so
briefly,
I'm
going
to
touch
on
a
few
different
things
for
folks
who
are
less
familiar
with
vault
I'm
gonna
give
a
quick
intro
there.
What
are
some
of
the
use
cases?
A
How
does
it
work
and
then,
from
there
talk
about
a
new
feature
that
I'm
very
excited
about
that
landed
in
vaults,
zero,
nine
and
then
talk
about
kubernetes
integration
since
we're
all
here
at
coop
con,
so
for
folks,
who've
never
heard
about
vaults.
You
know
the
way
we
like
to
describe
it.
Is
it
really
solves
three
different
challenges
that
are
all
pretty
related,
the
first
one,
which
is
really
why
vault
exists
came
out
of
the
need
to
deliver
secrets
to
our
end
applications.
A
So
as
we
adopt
tools
like
chef
and
puppet
and
kubernetes
and
get
sort
of
more
rich
in
our
orchestration
and
deployment
and
automation.
We
have
this
interesting
challenge,
which
is:
how
do
our
applications
actually
get
all
the
credentials?
They
need,
whether
it's
database
credentials,
whether
it's
cloudy
API
tokens,
whether
it's
TLS
SSL
certificates,
so
on
and
so
forth.
A
We
don't
want
to
pollute
all
of
that
with
sensitive
information
right,
because
otherwise
it's
being
stored
in
plain
text,
most
of
the
version
control
systems
we
use
are
not
really
designed
for
sensitive
materials,
so
they
don't
really
have
things
like
access
logs
and
you
know
fine
grain,
you
know
capabilities,
and
so
this
is
the
first
use
cases.
How
do
we
think
about
managing
this
privilege
information?
How
do
we
deliver
it
to
the
applications
that
need
it,
but
then
still
do
it
in
an
automated
way,
so
that
these
systems
don't
get
in
our
way.
A
Another
sort
of
interesting
class
of
challenge
is
great.
We're
delivering
our
database.
You
know
credentials
to
our
application
and
we're
giving
them.
You
know
a
32
by
encryption.
Key
and
saying
you
know,
god
be
with
you,
get
the
crypto
right,
this
kind
of
works,
but
what
we
find
in
practice
is
that
cryptography
is
really
really
hard
and
key
management
even
harder.
A
So
how
do
we
make
doing
security
right
a
lot
easier,
and
so
how
do
we
think
about
providing
higher-level
api's
things
like
encryption
as
a
service
so
that
we're
not
handing
an
application
30
to
random
bytes
and
saying
have
fun,
but
instead
providing
sort
of
higher-level
api's
that
are
less
error-prone
and
then
the
last
one
is
as
we're
doing
this.
What
about
the
people
right?
A
We've
spent
a
lot
of
time
talking
about
machines
and
automations
and
applications,
but
there
are
still
people
in
the
loop
right
so
as
how
do
we,
as
developers
and
operators
and
security
people
get
access
to
the
privileged
systems
that
we
need
right
and
the
last
bit
is
that
bit
it's
the
access
management,
so
with
that,
let's
jump
right
into
secret
management.
What
does
this
world
really
look?
Like
you
know,
it's
a
you
know,
I
think
it
starts
first
by
understanding
what
a
secret
actually
is.
A
The
way
we
like
to
think
about
it
is
it's
any
piece
of
information
that
you
can
use
for
authentication
or
authorization.
So
it's
something
that
I
can
provide
to
another
system.
That's
granting
me
access
to
it
or
proving
my
identity
or
elevating
my
capability
right.
So
here's
a
few
examples
of
it.
Sensitive
information
is
sort
of
a
different
class.
It's
things
we'd
like
to
keep
confidential,
but
don't
necessarily
grant
me
additional
access.
So
maybe
you
know
things
that
my
customers
order.
A
I
consider
that
sensitive,
but
it's
not
a
secret
piece
of
information,
it's
sensitive
and
so
the
open
questions
as
we
talk
about
secret
management
are
really
things
like.
Okay,
how
do
our
applications
get
these
secrets?
How
do
our
human
operators
get
these
secrets?
How
do
we
update
these
things?
What
happens
if
we
need
to
revoke
access?
How
do
we
know
who's
used?
What
and
what
are
we
doing
the
event
of
a
compromise?
A
These
are
sort
of
the
hard
questions
in
secret
management
that
we'd
like
to
have
an
answer
to
the
standard
kind
of
state
of
the
world.
I
guess
in
some
sense
of
the
answer
we
typically
see
to
many
of
these
questions
is
not
great.
Typically,
it's
it's.
What
we
would
define
a
secret
sprawl.
These
secrets
are
defined
everywhere,
whether
hard
coded
in
an
application
living
in
plain
text
in
a
config
file.
You
know
strewn
about
github,
or
you
know
our
puppet
servers
so
on
and
so
forth,
and
so
these
things
kind
of
live
everywhere.
A
As
a
result
of
this
there's
an
extreme
decentralization,
which
means
we
have
relatively
limited
visibility
into
who's.
Doing
what?
When
and
where
and
in
the
case
of
a
compromise,
we
have,
you
know
minimal
if
any
procedures
around
how
to
do
break
glass.
How
do
we
recover
from
this,
and
so
this
was
really
when
the
kind
of
problem
space
that
we
started.
A
And
if
we
do
that,
then
we
have
to
recognize
there's
two
very
different
audiences
for
the
secrets:
there's
our
applications
and
our
automation
tooling,
and
they
want
automated
API
driven
access.
And
then
we
have
our
human
operators
who
want
the
exact
opposite
of
that
right.
They
want
CL.
Is
they
want?
You
is
they
want
to
interact
with
it
in
a
very
different
way?
And
so,
as
we
think
about
these
things,
what's
the
right
place
to
be
on
the
spectrum
between
sort
of
theoretically,
perfect
security?
And
theoretically,
you
know
perfect
usability
right.
A
You
know
in
some
sense,
I
think
this
is
a
painful
trade-off,
but
it
is
one
that
we
have
to
deal
with
in
security
land.
We
can
create
these.
You
know
perfect
systems
that
are
so
difficult
to
use,
that
no
user
uses
them
right
and
that's
what
we
see
in
practice.
Those
organizations
who
adopt
these
things
and
it's
so
onerous
that
one
app
uses
it
and
everything
else
just
skips
it,
and
so
you
have
to
find
that
balance
of
it
being
practical
enough
that
applications
will
use
that.
A
So
as
we
translate
the
sort
of
top
line
goals,
we
had
what
does
that
mean
in
terms
of
the
feature
of
functionality
of
vault
itself
right?
The
sort
of
table
stakes
for
the
system
is
secure,
bit
storage
right
bits
in
bits
out
encrypted
at
rest,
encrypted
in
transit
and
that's
sort
of
table
stakes
where
I
think
things
start
getting
a
little
more
interesting
is
when
we
start
talking
about
dynamic
secrets
and
I'll,
get
into
that
and
there's
a
whole
notion
around.
A
How
do
we
generate
these
things
on
demand,
and
what
does
that
mean
in
terms
of
tracking
their
lifespan
and
dealing
with
things
like
revocation,
and
then
we
have
all
of
our
good?
You
know
bread-and-butter
security
things
right.
How
do
we
think
about
auditing?
How
do
we
think
about
fine-grained
access
control?
How
do
we
think
about
authentication,
and
so,
while
we're
doing
all
of
this,
what
are
the
set
of
principles
we
want
to
bring
to
bear
right
when
we
really
look
at
you
know
what
are
the
things
that
you
have
to
care
about?
A
When
you
look
at
security,
they
haven't
changed
a
whole
lot
right.
The
core
bread-and-butter
has
been
the
same
for
a
long
time
right.
We
want
to
provide
confidentiality
of
all
data,
that's
stored.
We
want
to
provide
integrity,
we
want
to
provide
high
availability,
but
then
more
so
we
want
to
do
things.
Like
least
privilege
right,
don't
give
access
unnecessarily,
because
when
someone
inevitably
gets
compromised
right,
there's
a
phishing
attack
and
they
push
the
link
right.
A
The
things
that
they're
allowed
to
access
will
be
accessed
and
so
minimizing
what
people
have
access
to
is
a
prudent
thing
to
do.
How
do
we
get
some
element
of
privilege
separation?
So
does
everyone
need
to
be
an
administrator?
Can
some
people
be
read-only
users?
How
do
we
sort
of
bracket?
Who
can
do
what
privilege
bracketing?
You
know
how
do
we
time
down
access
to
things?
So
access
doesn't
mean
access
forever
non-repudiation?
How
do
we
get
to
a
place
where
we
have
sufficient
audit
logging
that
we
can
say
with
certainty?
A
Someone
did
something
at
time,
and
then
how
do
we
apply
defense-in-depth?
How
do
we
not
put
all
of
our
eggs
in
one
basket,
and
so
as
we
go
through
all
these
things,
you
know
I'll
talk
about
how
we
kind
of
weave
some
of
these
principles
in
because
the
goal
is
to
bring
all
of
these
sort
of
security,
best
practices
into
the
way
Vault
works
into
the
workflow,
but
do
it
in
a
way
that's
sort
of
invisible,
you're
kind
of
applying
best
practices
without
having
to
be
overly
cognizant
of
it.
A
So,
like
I
mentioned,
the
table,
stakes
of
the
system
is
just
secure
bit
storage.
You
want
to
be
able
to
write
something
to
the
system
and
pull
it
back
out
and
that
should
be
secured
as
it's
going
over
the
network
secured
as
it's
at
rest,
and
so
of
course,
we
do
that
everything
at
rest
is
AES
256-bit
everything
over
the
wires
TLS
one
two.
All
this
is
pure
software,
so
there's
no
hardware,
security
modules
required
and
the
goal
here
is
providing
confidentiality
and
integrity.
A
Doing
it
is
actually
pretty
simple,
so
you
know
for
all
that
we've
mentioned
so
far.
This
is
what
it
you
know,
writing
a
secret
and
reading
it
back.
Would
look
like
so
here
we're
just
going
to
write
some
arbitrary
value
you
know
bar
is
equal
to
bacon
at
path,
secret,
foo,
the
system's
architected,
roughly
like
a
hierarchical
file
system
and
as
we
read
it
back,
we
get
our
arbitrary
bars
bacon
back
simple,
so,
like
I
said,
table
stakes
the
going
gets
interesting
when
we
start
talking
about
things
like
dynamic
secrets.
A
One
of
the
challenges
with
something
that's
just
a
static
bit
store,
I
put
in
bar,
is
equal
to
bacon.
Is
that
every
client?
That's
reading
that
value
out
sees
the
same
value
so
to
make
this
concrete?
If
I
have
50
web
servers
that
all
go
in
and
say,
give
me
the
database
password,
all
50
will
see
the
same
username
and
password,
and
so
now
we
have.
A
This
interesting
challenge
was
like
what,
if
that
thing
leaks,
which
node
was
the
point
of
compromised,
all
50
of
the
machines
were
using
the
same
credential
all
of
our
developers,
who
access
that
had
the
same
credential,
and
so
now
it's
really
hard
to
understand.
Okay,
where
was
the
source
of
the
problem,
so
we've
lost
that
non-repudiation.
We
can't
say
with
any
certainty
which
actor
was
responsible.
A
Instead,
what
we'd
like
to
be
able
to
have
is
a
unique
credential
per
client,
that's
generated
on
demand.
So
when
we
see
this
client
this
token
that
gets
leaked,
we
actually
have
a
very
high
level
certainty
that
actually
it
was
Armen
who
accessed
it
at
2:45
p.m.
and
that
credential
was
unique
to
him,
and
so
how
do
we
do
this?
This
mechanism
within
volt
is
called
dynamic,
seek,
and
so
there's
a
few
interesting
fall
outs
that
come
from
this
and
we'll
talk
about
them
at
the
highest
level.
The
way
it
works
is
pretty
simple.
A
Our
DBMS
system
pick
your
favorite,
no
sequel
systems,
pick
your
favorite
messaging
queues,
the
list
sort
of
goes
on
and
on-
and
this
is
made
possible,
because
this
is
a
plug-in
point.
So
what
we've
seen
is
the
communities
show
up
and
say:
hey
I
need
to
support
the
system
and
then
they're,
like
here's,
the
three
hundred
lines
of
code
that
connects
MongoDB
or
Cassandra
or
RabbitMQ,
and
this
plug-in
is
split
away
from
the
Corp.
A
What
this
comes
with,
then,
is:
if
the
secret
is
dynamic
and
unique
per
client,
we
need
some
way
of
tracking
it.
We
need
some
amount
of
metadata
so
that
we
know
which
client
has
access
to
what
and
if
these
things
are
time
bounded
when
do
they
expire,
and
so
vault
rolls
all
that
up
into
the
concept
of
Elise.
So
when
we
generate
a
dynamic
secret,
the
value
is
returned
back
with
Elise,
and
so
this
Li
says
this
is
for
you
Armand
it's
valid
for
the
next.
A
You
know
two
hours,
this
is
your
username
and
password,
and
the
lease
is
something
concrete
that
we
can
talk
about.
So
we
can
renew
a
lease.
We
can
revoke
a
lease.
We
can
query
what
are
the
outstanding
leases
in
the
system,
and
so
this
actually
lets
us
start
defining
break
loss
procedures.
So,
as
an
operator,
if
I
know
my
sequel
was
compromised,
but
I
don't
know
who
was
exactly
the
source,
I
can
go
to
vault
and
say
you
know
what
just
revoke
all
of
the
my
sequel
leases
and
then
we're
gonna.
A
So
why
do
this
this
seems
complicated?
It
seems
like
it
adds
a
lot
of
new
like
nuance
to
the
system,
partly
it's
because
it
gives
us
all
four
of
these
properties.
It
gives
us
this
notion
of
privilege
bracketing
so
that
when
I
give
you
a
credential
for
the
database,
it's
not
a
forever
credential
I
can't
I'm
bound
as
a
valid
four
day
a
week
a
month
and
I
can
have
some
guarantee
that
the
client
is
forced
to
move
on
to
a
new
credential,
otherwise
that
credential
just
gets
wiped
out.
A
I
get
non-repudiation,
so
I
know
of
my
50
web
servers.
This
one
was
the
point
of
compromise.
I
can
also
update.
I
can
bound
the
time
it
takes
for
a
secret
to
update
if
I
know,
every
client
is
forced
to
play
ball
and
respect
this
lease
contract.
Then
I
have
some
certainty
that
if
I
change
my
policy
that,
within
the
time
bound
of
the
leases,
all
of
my
clients
are
gonna,
get
the
updated
version
and
then
the
last
one
is.
It
enables
revocation,
because
now
we
have
this
rich
metadata
on.
A
So
then
we
get
the
sort
of
security,
bread-and-butter,
the
authentication,
authorization
and
auditing.
As
far
as
authors
authentication
goes,
this
is
kind
of
an
interesting
part,
because
here
we
have
the
split
between
what
machines
want
to
use
and
what
applications
want
to
use
as
an
application
you're
not
going
to
log
in
with
a
username
and
password
right
and
enter
to
a
fake
code.
You
have
to
be
able
to
use
something
like
mutual
TLS
bearer
tokens.
A
You
know
another
mechanism,
we
have
call
a
perl
which
is
like
a
username
and
password
for
applications,
and
then
users
are
gonna.
Do
things
like
single
sign-on
with
LDAP
or
Active
Directory?
Maybe
you
know
an
OAuth
provider
like
github,
something
like
that
a
little
more
human
friendly
and
what
we
do
within
vault
is
basically
map
down
these
different
authentication
mechanisms
into
a
uniform
authorization
language.
A
So
you
apply
a
consistent
set
of
policy
over
the
different
users
of
the
system,
whether
they're
an
application
or
a
user,
and
so,
while
there's
many
many
different
authentication,
backends
there's
one
way
you
handle
authorization
and
the
system
models
this
as
a
Fulton
I
sort
of
system.
So
it's
a
need-to-know
basis,
and
this
is
really
in
keeping
with
lease
privilege.
Unless
you
really
need
access
to
a
secret,
you
probably
shouldn't
have
it
because
that's
just
an
unnecessary
surface
area
of
attack
and
then
with
request/response
logging.
A
Everything
can
flow
through
a
number
of
audit
backends,
so
you
can
configure.
You
know
one
to
n
audit
back
ends
and
the
idea
behind
allowing
multiple
is.
It
allows
us
to
design
the
system
in
a
fail
closed
way.
So
we
can
allow
you
to
set
up
two
different
auditing
backends
and
then
make
the
assertion
that
if
none
of
the
backends
allow
the
the
request
to
get
logged,
the
system
rejects
the
request.
So
why
would
you
do
this?
This
allows
us
to
protect
that
non-repudiation
property.
A
So
if
I
as
a
malicious
operator
know
how
the
system
is
set
up,
I
don't
go
in
and
just
turn
off
Splunk
for
a
little
while
pull
out
a
bunch
of
secrets,
and
then
you
know
now
that
it's
convenient
turns
Splunk
back
on
instead
you'd
much
rather
the
system
say
you
know
what
I
can't
log
this.
So,
no
it's
better
to
have
an
audit
trail
than
to
be
have
the
sort
of
gap
in
the
history.
A
So
one
of
the
interesting
properties
of
a
system
like
this
is
that
you're
pulling
secrets
out
from
it
for
your
app
to
actually
be
able
to
function.
Your
app
doesn't
have
the
database
credential
until
it
talks
to
vaulting
and
gets
it,
and
so
you
kind
of
care
about
availability
of
a
system
like
this
right
so
from
very,
very
beginning,
volt
0.1.
The
system
was
highly
available
at
that
time.
A
It
only
supported
console
now
it
sports
at
CD
and
zookeeper,
and
a
few
other
systems
for
doing
a
leader
election,
and
so
you
can
appoint
fall
at
these
systems
and
it
will
automatically
do
an
active
standby
model.
So
one
of
the
bolts
becomes
active
and
services
requests.
The
other
ones
forward,
things
to
the
active
instance
and
if
it
fails,
will
automatically
flip
over
to
one
of
the
standbys,
and
this
is
providing
high
availability.
A
One
of
the
challenges
of
vault
is,
if
we're
providing
this
promise,
where
we
say
data
is
encrypted
in
transit
and
at
rest,
it
means
we're
encrypting,
vaults,
own
data,
and
so
when
vault
starts,
it
has
an
interesting
problem,
which
is
how
does
it
decrypt
its
own
data?
One
of
the
decisions
we
made
very
very
early
on
was
to
say
this
key
must
be
provided
online.
A
We
would
just
go
to
the
cold
storage
decrypt,
whatever
we
wanted,
since
we
have
the
decryption
key
and
not
bother
with
auditing
and
access
controls,
and
so
we
have
to
be
very,
very
sensitive
with
this
particular
key,
particularly,
we
have
to
be
worried
about
insider
attack,
people
who
do
have
access
to
the
system
and
may
have
access
to
this
key.
So
the
approach
we
take
is
what's
referred
to
as
a
multi
man
rule
and
the
idea
behind
it
is
you
actually
just
don't
give
out
the
master
key
to
anyone.
A
So
if
all
has
this
notion
of
a
key
hierarchy,
so
the
sort
of
most
inner
keys,
the
keys
that
protect
all
of
the
data,
vault
stores
are
referred
to
as
encryption
keys,
these
can
be
rotated
online
all
day
and
night.
Nobody
has
access
to
these
things.
There's
sort
of
an
internal
detail
that
key
that
key
ring
I
should
say,
is
protected
by
the
master
key.
A
A
This
can
be
slightly
annoying
if
we're
doing
automation
and
doing
things
like
putting
it
inside
of
you
know,
systems
that
are
gonna
move
us
around.
So
there
are
mechanisms
for
doing
it
in
an
automated
way
effectively
we
replace
our
human
key
holders
with
a
machine
key
holder
that
we
trust,
and
so
this
could
either
be.
You
know
a
hardware
security
module
that
we're
wracking
or
we
say
you
know
what
we
trust
our
cloud
provider
enough
to
be
our
key
holder
and
we're
gonna
delegate
this
to
them.
A
A
The
sort
of
sprawl
of
definition
where
we
have
low
access
control,
low
visibility,
bring
it
all
into
one
place
where
we
can
have
a
uniform
policy
uniform
way
of
auditing
uniform
way
of
authorizing
everything,
and
in
doing
so
we're
really
thinking
about
two
different
types
of
threats.
The
bigger
more
real
one
is
insider
threat.
It's
you
know,
folks
that
should
have
some
access
to
the
system.
A
You
know
it's
people
who
are
inside
our
org
and
have
access
to
our
private
github
and
all
of
our
keys
and
passwords
are
in
there
right,
and
so
how
do
we
think
about
that?
That's
really
about
imposing
things
like
ACLs
and
secret,
sharing
and
sort
of
isolation
of
the
of
the
secrets
and
then
there's
the
external
threat
problem.
People
should
have
no
access
to
the
system
at
all
and
that's
really
where
having
a
strong
crypto
system
comes
into
play.
A
So
for
folks
that
are
familiar
with
fall
and
maybe
started
using
it
earlier,
a
future
that
we,
you
know
recently
announced
in
vault
0.9,
which
is
only
a
few
weeks,
is
the
stronger
notion
of
identity
and
so
what
at
its
core?
What
this
is
really
about
is
saying
you
know
what
there's
actually
entities
who
are
gonna
use
the
system
and
interact
with
the
system
in
a
sort
of
a
longer-term
persistent
way
like
Arman,
as
a
user
is
going
to
interact
with
us
on
a
daily
weekly
monthly
basis,
and
so
there's
a
kind
of
different
things.
A
You
can
do
different
ways
of
thinking
about
it.
When
you
actually
model
these
entities
of
the
first
class
thing,
so
an
entity
could
be
a
single
person,
it
could
be
a
single
system,
it
could
be
a
single
application.
It's
sort
of
a
you
know,
a
bit
of
a
flexible
concept
in
that
sense
and
what
it
lets
us
do
is
assign
policies
and
metadata
to
an
entity.
A
What
this
lets
us
do
once
we
start
modeling
in
this
more
sort
of
first-class
way
is
start
grouping.
People
together,
so
entities
can
be
placed
into
arbitrary
group
hierarchies.
So
then
you
can
start
building
sort
of
a
group
notion
in
a
much
richer
way
right,
and
so
you
know,
one
question
is
like
well.
Why
deal
with
this
in
volt?
If
I
have
a
notion
of
groups
and
something
like
LDAP,
the
challenge
becomes.
A
How
do
you
start
bridging
all
this,
where
you
have
one
set
of
apps
where
your
source
of
truth,
your
sort
of
set
of
trust,
is
Amazon
you're
using
Amazon
as
a
trusted
third
party
to
say:
hey.
This
is
a
web
server,
and
then
you
have
users
who
are
coming
in
via
LDAP,
and
you
have
a
separate
set
of
applications.
A
They're
authenticating
against
your
kubernetes
cluster
and
gke,
there's
no
longer
a
single
identity
provider
right,
there's,
no
single
source
of
truth
of
who's
in
my
web
server
group
right-
and
you
know
my
kubernetes
cluster
being
in
my
web
server
group
means
I'm
a
pod
with
a
particular
tag
and
Amazon.
It
might
mean
I
have
a
certain
tag
on
my
VM
or
I'm,
a
certain
ami
and
an
LDAP.
A
A
So
I
can
just
go
in
and
say
you
know
what
my
whole
web
dev
group
has
one
set
of
authorization
and
it
doesn't
matter
whether
they're
authenticating
against
my
my
kubernetes
cluster
or
as
an
Amazon
ami
or
they're
coming
in
via
LDAP,
and
so
that's
what
it's
really
about
is
allowing
it
to
be
much
simpler
to
have
this
consistent
way
of
doing
it.
So
you're
not
sort
of
repeating
the
work
three
or
four
times
I
guess
I
should
just
gone
to
this
slide.
But,
yes,
the
basic
idea
is
based
bridging
across
multiple
different
sources.
A
So
moving
on
a
little
bit
now
is
the
kubernetes
off
back-end.
We
released
this
one
with
vault
zero,
eight
three
and
we
work
pretty
closely
with
the
folks
at
Google
and
other
members
of
the
community
who
have
much
more
expertise
in
the
platform
than
we
do,
and
so
the
basic
idea,
the
very
very
highest
level,
is:
how
do
we
bind
something
in
kubernetes?
That's
going
to
provide
a
sense
of
identity
for
our
application,
our
pod
to
something
that
vault
can
actually
verify.
A
You
know
in
a
in
a
sort
of
a
cryptographically
trustable
way
that
that
we
can
assert
strongly
the
identity
of
the
other
end.
Basically,
the
caller,
and
so
the
mechanism
that
vault
really
relies
on
here
is
the
notion
of
a
service
account,
and
so
what
we're
doing
is
binding
roles
within
vault
to
roles
within
kubernetes.
Using
these
shared
service
accounts.
The
nice
thing
about
doing
those
is
that
we
have
this
cryptographic
property.
A
We
can
lean
on
of
the
JWT
s
to
actually
make
sure
that
hey
is
this
just
a
fabricated
thing
the
pod
has
come
up
with,
or
is
this
actually
officially
signed
by
the
platform
that
we're
trusting
and
the
nice
thing
is
because
these
are
built
into
kubernetes
already,
there's
no
additional
moving
pieces
so
for
folks
have
been
kind
of
following
the
kind
of
vault
and
kubernetes.
You
know
the
the
evolution
of
the
integration
story
for
a
while
there
was
a
few
different
approaches,
but
they
required
using
different
service
brokers.
A
So
there
was
a
few
different
moving
pieces
that
you
had
to
kind
of
coordinate
and
as
different
api's
would
break
on
the
two
sides
you
had
to
kind
of
you
were.
You
were
getting
of
the
paper
cuts
of
that.
So
the
nice
thing
here
is
it's
a
pure
native
integration
of
all
it's
a
pure
native
integration
in
kubernetes
and
there's
no
additional
moving
pieces
so
just
to
flow
through
what
does
it
actually
look
like
sort
of,
as
as
the
kind
of
the
bits
flow
in
this
sort
of
starting
state?
A
We
have
volt
running
somewhere,
maybe
within
kubernetes,
maybe
the
outside
of
Cooper
neighs
doesn't
matter
for
this
example,
and
then
we
have
a
pod.
That's
been
scheduled
somewhere
with
a
service
account
token.
So
the
first
thing
that
happens
is
when
our
container
boots
it's
reading.
The
service
accounts
jot.
This
might
be
the
app
or
it
might
be
a
sidecar.
That's
doing
some
of
those
lifting
on
behalf
of
the
app,
but
we
read
the
jot.
A
Then
we
send
it
over
to
vault
and
say
here's
a
thing
that
should
prove
that
I
am
who
I
say:
I
am
I'd
like
to
have
access
to
vault.
Now,
then,
what
vault
does
is
verified
that
this
shot
is
actually
cryptographically,
signed
and
valid.
This
thing
says
it
is
who
it
claims
to
be,
and
then
we
go
even
further
and
call
into
kubernetes
touken
review
api
and
say:
can
you
also
verify
this
and
return
any
additional
information
you
might
have
about?
A
You
know
this
entity
and
then,
finally,
once
we've
checked
it
out,
everything
is
verified
and
it
looks
good
to
go.
Then
we
return
the
token
back
to
the
container,
and
at
this
point
the
container
is
holding
a
volt
token.
So
the
nice
thing
about
this
integration,
as
opposed
to
a
few
others
that
were
sort
of
considered,
is
this
means
the
application
can
make
use
of
any
of
volts
capabilities.
A
So
not
just
thinking
about
full
as
sort
of
a
back-end
for
kubernetes
secrets,
where
we're
going
to
just
do
treat
it
as
sort
of
a
BitLocker,
but
we
can
actually
leverage
dynamic
secrets,
cryptographic,
offload,
dynamic,
SSL
Certificates,
the
whole
sort
of
gamut
of
vault
is
available
because
we
have
an
actual
vault
token
in
terms
of
how
we
actually
configure
this
thing.
It's
relatively
straightforward,
so
the
first
thing
we
do
in
vault
land
is
enable
the
Cooper
naze
back-end.
A
So
everything
involves
sort
of
off-white
of
a
default,
so
you
have
to
sort
opt-in,
so
we
opt
in
and
say:
ok,
I'm
gonna
set
up
a
kubernetes
back-end
as
a
system
that
I
trust
and
then
the
first
thing
we
have
to
do
is
configure
it
and
say
you
know:
where
is
the
kubernetes
cluster?
You
know
what
are
those
you
know,
the
CA
certificates?
How
do
we
establish
trust
of
the
platform
that
we
want
to
authenticate
against?
So
this
is
sort
of
a
one-time
configuration.
A
We
set
up
the
the
sort
of
linkage
between
vault
and
our
cluster,
then
what
we
do
is
for
each
role
that
we
care
about.
This
might
be
on
sort
of
a
per
service
level.
We
define
what
that
mapping
is
between.
You
know
something
we
trust
in
kubernetes
and
the
policy
definitions
within
vault.
So
here
we're
just
writing
a
you
know,
a
demo
role
where
we
say.
A
Ok,
if
you
see
anything
that
has
the
vault
earth
service
account
in
the
default
namespace
map
that
into
vaults
kuvasz
policy,
so
anything
that
logs
in
with
that
service,
account,
will
get
whatever
is
granted
to
it
by
the
crew
bath
policy
within
vault
and
then
on
the
side
of
the
client.
Let's
say
now:
we've
actually
scheduled
something
that
has
access
to
that
shot.
A
It
boots
up
grabs
its
shot
and
it's
effectively
issuing
at
the
API
equivalent
of
this
call,
probably
not
using
the
CLI
and
providing
the
shot
and
saying
hey
I'm
logging
in
as
this
demo
role,
and
so
once
of
all
verifies
it.
You
know
out
comes
the
token,
so
here
we'll
see
sort
of
the
standard
login
or
we're
getting
a
token
back,
as
well
as
the
policy
that's
associated.
In
this
case,
we
can
see
the
default
as
well
as
the
coup.
A
A
So
briefly,
just
to
close
out.
You
know
when
we
think
about
volt
there's
these
three
primary
kind
of
things
we
talked
about
the
first
one
is
really
secret
management
and
how
we
thread
through
these
credentials,
especially
in
an
automated
way
right.
What
we
don't
want
to
do
is
boot
a
machine
and
then
file
a
ticket
against
our
security
team
and
say
by
the
way
this
machine
is
running
somewhere.
You
know
please
go
get
a
database
password
and
put
it
on
on
that
machine.
A
Right,
we'd
like
to
be
able
to
do
end-to-end
automation
and
bring
our
secrets
along
with
us.
The
second
use
case
that
we
didn't
talk
about
at
all
as
encryption
as
a
service
which
really
is
about
how
do
we
push
the
key
management
out
of
our
applications
and
up
Deauville
and
let
vault
handle
key
versioning,
key
rotation
and
key
decommissioning
and
then
just
provide
high-level
api,
so
say
encrypt
decrypt
sign
verify
a
whole
nine
yards
and
the
final
bit
is
great:
we've
centralized
all
this
we've
achieved.
You
know:
we've
defeated
secret
sprawl.
A
Everything
is
in
one
place.
How
do
our
human
operators
access
everything
right?
We
don't
want
them
to
interface.
Just
with
you
know,
an
API
that
that's
sort
of
painful,
so
instead
really
thinking
about
identity
and
access,
control
and
sort
of
user
management
as
a
first-class
challenge
within
volt,
and
so
within
that
we
sort
of
talked
on
on
the
secret
management
bits.
We
talked
about
the
kubernetes
integration,
but
there's
lots
and
lots.
We
didn't
cover.
A
So
if
this
is
interesting,
please
check
out
either
bolts
website
or
you
know,
search
YouTube,
there's
a
bunch
of
other
talks
on
this
or
check
out
the
house.
Schubert
blog.
Thank
you.
So
much-
and
you
know
quick,
there's
some
stickers
up
in
the
front.
So
if
you
lose
any
of
the
hash
controls,
vault
included,
please
help
yourself
thanks
so
much.