►
From YouTube: Managing Kuma Tokens with HashiCorp Vault
Description
Managing tokens in Kuma can be a challenging and manual process. Both the user and dataplane token lifetimes need to be manually tracked and managed. This ultimately becomes a burden for DevOps, and long life tokens end up being used.
In this session, you will learn how to:
- Leverage a secret engine like Hashicorp Vault to automate Kuma access and token management.
- Dynamically create, manage, rotate, and revoke both user and dataplane tokens based on lifetime.
- Set up auto-rotation for simple management of shorter TTL Tokens.
- Leverage different auth methods for token requests — for example, Github for users or IAM for services.
Kong Builders is a livestream series that takes our developer-focused toolsets and puts them on display in the best venue possible – building applications and connecting workloads.
#KongBuilders #developer #livestream #livecoding
A
A
A
B
B
B
What
we
do
with
konk
and
as
a
reminder
in
the
Kong
Builders
we
doing
some
stuff
live
and
some
things
will
break
eventually
during
during
this
live
stream,
and
today
I'm
a
super
excited
that
I'm
not
alone
in
my
studio
I'll,
have
my
friend
Greg
Hunt,
to
talk
to
me
a
little
bit
about
stuff
that
he
did
for
combios.
Greg.
Welcome
to
con
dealers.
B
B
We
talked
about
Kuma
and
we
we
thought
that
okay,
so
not
many
of
you
were
able
to
join
us,
and
since
we
didn't
do
any
kind
of
like
a
formal
recording
of
this
stuff,
we
will
start
bringing
some
of
the
guests
from
our
Kong
builders
for
four-hour,
cold,
Builders
or
con
Casio.
So
before
we
jump
right
in,
let
me
see
if
we
are
okay.
We
see
that
the
people
are
seeing
us
here
and
looks
like
they.
B
So
let's
do
a
quick
round
like
where
are
we
coming
from
and
what's
your
level
of
using
Kong?
So
let's,
let's
do
some
some
comments.
I
see
some
of
the
some
of
the
regulars
here.
Let's
see,
thank
you
so
much
for
showing
up
and
showing
some
love
to
con
demos.
That's
what
we
do
here:
gateways
gateways
and
pipelines,
cool,
stuff,
okay
and
yes,
our
Kong
Kong
says
welcome
everyone.
B
So
it
looks
like
everything
working
I
haven't
done
this
for
a
while
and
and
maybe
something
will
bring,
but
let's
before
we
jump
like
Greg.
What
brings
you
here
like
when
you
start
using
this
stuff?
How
you,
you
know,
build
your
expertise
in
the
in
the
in
the
fields
of
of
service
mesh
and
like
what
are
you
going
to
be
showing
us
today.
C
B
C
Also
I'll
give
that
team.
They
have
a
a
monthly
Community
Meetup
type
session.
You
should
join
if
you're
interested
in
service
mesh,
because
they
are
always
willing
to
talk
to
anybody
who
joins
and
very
open,
and
you
will
not
find
that
in
a
lot
of
other
service
meshes
where
you
can
actually
talk
to
the
developers
and
kind
of
have
a
if,
if
you're
using
it,
you
know,
can
kind
of
help
mold
the
direction
of
of
the
product
and.
B
B
So
you
will
get
all
things
all
things
service
mesh,
all
things
Kuma
all
things
Kong
in
this
Channel,
all
right
so
and
so
as
I
mentioned,
Greg
was
a
speaker
for
at
the
Kong
Summit
and
he
shared
some
of
the
experience
that
he
developed
around.
Managing
some
of
the
I
would
say
it's
quite
challenging.
Topic
in
general,
like
I,
will
I
will
pass
this
to
so
Greggs
and
he
can
talk
a
little
bit
about
this,
and
I
will
be
here.
B
C
Tokens
was
a
one-time
thing
and
it
tended
to
be
long-lived
tokens
and
we
said:
well,
that's
not
really
great
practice.
So
what
we
should
do
is
we
should
be
able
to
manage
these
more
dynamically
and
we're,
like
you
know,
Vault
actually
does
a
really
good
job
of
managing
job
tokens
dynamically.
So
we.
C
B
Because
Lauren
says
hi
from
Friends,
we
got
our
another
champion.
Merch
comes
from
LinkedIn
this
time
and
he
says
that
they
running
a
10
services
in
tackle
moving
to
Kuma
to
get
more
manageable
architecture
and
the
20
TV
heard
some
bad
news
about
jot
lately.
So
Tony
do
tell.
While
we
will
continue,
throw
this
some
of
these
some
of
the
news
and
we'll
get
him
back.
C
The
problem
is
token
management
right
now.
This
is
a
very
manual
process
driven
by
policy.
This
is
a
time
consuming
process
because
you
need
to
go
especially
if
you're
in
a
larger
organization,
you
need
to
actually
go
through
request.
Someone
to
generate
you
a
token.
Send
you
a
token
which
also
requires
causes
delayed
access.
This
can
be
error
prone.
C
If
you
don't
properly
request
the
Scopes
and
those
tokens
are
properly
request,
then
you
have
to
then
go
back
to
the
beginning
and
re
redo
this
and
it
ends
up
not
being
sustainable
and
what
eventually
happens
is
people
circumvent
it?
They
create
tokens
with
too
high
permissions
so
that
they
don't
have
to
keep
going
back
and
and
asking
for
tokens
ultimately
that
ends
up
leaking
secrets.
B
C
Yeah
yeah,
so
what
what
these
tokens
do?
Is
they
allow
services
to
join
the
mesh
right?
So
in
order
for
you
to
join
the
mesh,
you
need
to
prove
that
you
are
the
service
you
are
and
inside
of
the
and
so
Kuma
takes
the
your
permissions
and
and
bakes
them
into
the
token.
And
so
then,
when
you
go
to
join
the
mesh,
you
have
a
config
file
for
the
data
plane.
That
tells
you
what
you're
going
to
do.
C
It
then
compares
the
token
the
permission
in
the
token
to
the
permissions
in
your
config
file
and
if
those
don't
match
it
doesn't
allow
you
to
join
the
mesh,
and
so
that's
a
way
for
services
to
be
able
to
join
the
mesh
and
verify
they.
You
know
that
you
don't
have
a
rogue
service,
try
and
join
your
mesh
and
then
you
route
traffic
to
it
or
then
it
interacts
with
other
services
in
your
mesh,
and
so
that's
that's
the
purpose
of
these
tokens
and-
and
so
that's.
B
What
and
again
here's
here's
a
very
important
thing
that
we
would
like
to
point
out
is
that
essentially
in
the
kubernetes,
some
of
this
automation
is
handled
by
some
of
the
like.
When
you
do
injection
of
the
of
the
sidecar.
Some
of
the
configuration
will
be
shipped
here,
but
in
an
environments
where
are
not
kubernetes,
the
you
know,
things
with
adding
services
to
to
the
mesh
would
be.
You
know
slightly
slightly
different,
and
this
solution
should
work.
D
C
Right
and
in
kubernetes,
you
have,
you
know
the
service,
the
service
access
tokens
that
that
can
kind
of
help
with
that
right,
and
so
you
can
write
rules
around
those
access
tokens
where
outside
of
kubernetes
world,
you
have
to
kind
of
maintain.
You
know,
handle
that
separately
and
that's
really
the
the
solution,
we're
kind
of
driving
through
here.
C
C
B
C
C
Now
in
that
workflow
as
well
as
a
user,
you
would
authenticate
with
your
ldap
grids
you.
The
Vault
would
then
hit
ldap
and
make
and
verify
those
creds.
It
would
then
pull
the
associated
policies
attached,
give
you
and
then
return
you
a
vault
token
with
those
attached
policies
and
then
with
those
policies.
You
can
then
request.
Secrets
inside
of
Vault.
C
All
right
so
then
we're
going
to
explain
how
our
specific
workflow
works
with
that,
so
we're
going
to
run
a
vault
agent
on
side
of
an
on
our
system.
Our
vault
agent
is
basically
just
a
long
running
process
that
will
actually
be
able
to
authenticate
as
a
service
inside
of
our
service,
we're
going
to
be
using
aperol,
which
is
basically
a
secret
and
an
ID
that
we
inject
inside
of
our
services.
C
But
you
could
very
easily
use
an
IAM
any
sort
of
cloud
metadata
as
your
authentication
process
as
well,
which
would
be
more
common
in
a
real
world
case,
I'm
running
a
local
instance.
So
we're
going
to
use
aperol
to
kind
of
simulate
that
that
I
am
metadata
for
authentication.
So
you
would
authenticate
against
Vault
and
then
so
what
the
agent
will
do
is
we'll
authenticate
this
install
and
then
get
back
a
vault
token.
Now
we're
not
interested
in
the
vault
token
we're
interested
in
the
kuma
token.
C
Token
and
then
on
behalf
then
after
it
will
then
actually
take
that
data
plane
token
and
start
the
data
plane
service,
which
will
join
our
policy
on
the
back
end,
while
when
we
make
that
request
to
the
data
plane,
token
Vault
actually
on
our
behalf,
goes
and
uses
an
admin
token
to
generate
the
control
plane
token
and
then
return
that
back
and
then
proxies
that
through
what's
cool
about
vault
is
Vault
keeps
that
stuff
in
memory
it
doesn't
actually
ever
store
the
actual
token.
So
it's
it
maintains
its
secrecy
through
the
entire
time.
C
So
only
this
user
will
end
up
with
that
token,
then
they
usually,
then
they
can
use
that
token
to
join
the
data
plane.
Obviously
so,
next
all
right,
so
then
we're
going
to
show
the
plugin
in
action.
Now
here's
a
GitHub
links
to
both
the
demo
I'm
going
to
show
today
and
the
plugin
they're
publicly
out
there
on
GitHub.
You
can
take
a
look.
Please
feel
free
to
put
in
issues
make
comments.
Make
suggestions
make
PRS
as
you.
C
Okay,
so
I'm
using
Shipyard
as
my
engine
Shipyard,
is
a
a
demo
tool
that
is
really
kind
of
like
Docker
compose,
with
with
dependency
built
into
it
and
so
I'm,
and
also
on
top
of
that
it
has
document
interactive
documentation.
You
can
build
into
it.
So
that's
what
we're
going
to
drive
today,
so
I'm
gonna
run
the
shipyard
blueprint,
which
is
essentially
what
the
demo
repo
is,
is
the
shipyard
blueprint
all
you
need.
C
On
I
certainly
will
yes
all
right.
So
here
is
my
Shipyard
blueprint,
so
what
I
have
is
I
have
a
in
here
I
have
my
Kuma
control
plane,
which
I
actually
created
as
another
blueprint,
so
it
could
be
reused,
it's
like
a
module
inside
of
it,
and
this
is
just
a
basic
control
plane
inside
of
the
can
you
build
a
network
inside
of
Kuma,
which
is
just
a
Docker
Network
in
here
you
can
copy
files,
so
I
create
a
a
backend
file
that
I
can.
C
It's
very
similar,
yeah,
and
it
was
it
was
written
by
Shipyard
itself-
was
written,
is
written
and
maintained
by
Nick,
Jackson
and
Eric
belt,
who
are
both
Dia?
You
know
European
DA's
for
hashicorp,
but
it's
great
for
doing
dependencies
and
that
that's
what
makes
it
really
nice
in
this
instance.
So
now
throughout
here,
I
have
a
series
of
HCL
files
that
are
managing
the
different
other
components,
so
in
I
have
Kong
or
I
have
a
container
I
tell
see.
C
I
have
my
dependencies
that
these
other
things
need
to
have
run
first
before
it
can
bootstrap
up
these
containers.
I
can
add
volumes
directly
into
here,
like
the
app
roll
secrets
that
I'm,
injecting
into
these
different
containers
very
similar
to
a
way
an
IM
metadata
would
do
as
well
as
things
like
the
address
of
Vault
and
things
like
that.
I
have
a
container
that's
running
Vault
inside
of
there
I
have
a
config
script
that
can
script.
C
Config
script
goes
through
and
it
creates
the
default
Kuma
config
Secrets
engine
configures,
It
For
Me,
based
on
my
URLs,
and
then
creates
a
number
of
roles
for
this
specific
demo.
So
that
happens
there
and
then,
though,
and
then
it
also
generates
the
aperol
secrets
and
IDs
which
it
saves
out
the
files
which
then
are
mounted
as
volumes
into
the
other,
both
the
Kong
and
the
the
payments
then
and
then
several
other
the
database
in
the
back
end
pieces,
so
that
that's
how
kind
of
that
works?
I
said
you
can
go.
B
C
B
C
So
we'll
go
and
we'll
hit
our.
So
when
we
first
come
up,
there
was
no
connection
and
then
once
Kuma
all
the
data
planes
came
up.
Everything
was
connected,
so
this
is
fake.
Service.
Fake
service
gives
me
a
GUI
implementation
of
how
we're
connected
so
I
have
so.
This
is
the
Kong
API
or
the
Kong
container.
That's
running
and
I'm,
hitting
Port
8000
and
I'm,
hitting
the
UI
on
that
container.
D
B
You,
like
a
first
time
seeing
this
the
kuma
UI
Kuma
UI
is
a
part
of
control
plane.
So,
if
you
deploy
control
plane,
you
will
be
able
to
access
to
GUI
and
see
some
of
the
things
that's
happened
and
also,
if
you
can
scroll
on
the
light
on
the
left
side,
a
little
bit,
you
will
see.
There's
two
types
of
data
planes.
There's
the
standard.
C
B
C
C
That's
one
of
the
things
they
they
need
to
match
and
it
verifies
this,
and
if
they
don't
it
actually
doesn't
allow
you
to
join
the
mesh
so
yeah,
and
this
this
is
very
zoomed
in
so
that
you
can
see
on
the
screen
today
when,
if
you
zoom
out
and
you're
running
it
locally,
you
can
see.
The
dashboard
on
on
a
large
monitor
is:
has
everything
very
easy
to.
B
C
B
C
All
right
so
now
I'm
going
to
go
through
the
interactive
documentation
inside
of
Shipyard,
so
in
Shipyard
boots
up
it
will
have
a
docs
endpoint
if
you
configure
and
in
that
docs
endpoint
I've
gone
through
and
gone
through.
The
different
set
up
this
interactive
demo
that
we
can
just
drive
right
through
with
that.
It
actually
has
small
little
terminals
here
that
are
actually
mounted
to
these
different
boxes.
So
this
one
is
local.
This
one
is
in
the
kuma
container.
C
This
is
in
the
vault
client
I
have
a
vault
client
sitting
that
I
can
show
how
to
interact
with
with
Vault
and
then
the
actual
Vault
server.
So
all
right.
So
installing
and
configuring
the
plugins
first
thing
we're
going
to
talk
about.
How
would
you
actually
just
install
this
plugin
in
your
own,
your
own
system
right,
so
we're
going
to
check
to
make
sure
that
we
have
a
cut
connection
with
Vault,
so
we
hit
the
Vault
status
on
the
Vault
client.
This
gives
back
the
information
about
Vault.
C
Yes,
it's
up
it's
up
and
running.
We
can
also
go
to
the
GUI
and
I
use
the
super
secret
password
in
order
to
show
you.
This
is
our
initial
Vault
instance,
and
it
actually
has
the
one
Kuma
plug-in
installed
right
there.
So
then,
what
we're
going
to
do
now
is
and
I'm
going
to
make
this
bigger
as
I
go
through
here
yeah
there
we
go
all
right,
so
the
next
thing
you
want
to
do
is
you
want
to
register
the
plugin
with
Vault.
C
B
C
C
It's
it's
yeah,
I
believe
yeah
and
it's
a
defined
set.
So
basically
and
when
you
go
to
build
a
plug-in,
you
get
a
basic
like
it's
all,
it's
all
in
go,
so
you
get
a
go
shell
and
which
has
specific
endpoints
stubbed
out
and
then
those
are
the
calls
that
it's
expecting
to
get.
And
then
you
then
Implement
your
implementation
from
those
those
endpoints.
B
B
C
Run
that
on
our
client,
we're
going
to
write
the
command
in
here,
and
you
can
see
that
that
actually
writes
that
plugin
just
like
it
was
there,
and
you
can
see
that
that
was
successful.
All
right
so
now.
The
next
thing
you
want
to
do
is
enable
the
plugin.
So
we
already
have
one
called
Kuma.
Each
path
needs
to
be
unique.
We're
going
to
do
another
one
called
Kuma
guide,
just
as
an
example
to
show
how
that
process
would
work.
C
So
we
need
to
enable
the
secrets,
so
the
plugin
is
there,
the
plugin
is
registered
and
the
shaw
is
set
for
the
binary.
For
that
specific
one.
Now
we
need
to
actually
tell
Vault
hey
use
this
plugin.
So
what
we're
going
to
do
is
we're
going
to
run
this
Command
right
here
into
the
Vault
client
terminal.
C
So
now
we
run
this
command.
Vault
Secrets
enable
we're
going
to
add
path,
Kuma
guide
and
then
we're
going
to
tell
it
that
we
want
to
use
the
Vault
plug-in
Kuma
to
do
that,
and
you
see
we
get
a
success
back
and
it's
created
a
secret
engine
at
Kuma
guide.
So
if
we
go
back
to
Vault
and
we
go
here-
you
see
now
we
have
another
one
Kuma
guide,
that's
the
one
we
just
created
right
now
and
that
is
the
the
kuma
Secrets
engine.
All
right
go
back
to
our
documentation
here,
all
right!
C
So
then,
after
that
you
have
it
up
and
working,
but
it's
not
configured
yet.
So
what
we're
going
to
do
is
we're
going
to
configure
it
in
order
to
configure
it
right
now.
You
basically
need
two.
You
only
need
two
things.
You
need
the
URL
to
the
kuma
control
plane
that
you
want
to
create
tokens
for
one
cool
thing
about
this
is
actually
because
you
can
have
multiple
routes
here
of
the
same
plugins.
C
C
C
C
C
Correct,
that's
exactly
right,
yeah
and
in
this
case,
that
admin
token
is
stored,
persisted
in
in
the
vault
Secrets
engine
in
such
a
way
that
it
can't
actually
be
pulled
back
out.
You
can
view
the
URL
in
the
config,
which
you
cannot
once
once
you
post
that
in
there
you
can't
pull
that
that
back
out.
C
So
so
then
we
will
do
so
here
we
have
actually.
So
if
I
go
back
to
my
client,
you
can
see
this
is
interactive
because
I'm
going
to
do
a
print
in-
and
this
is
actually
this
isn't
just
like
visual
here.
This
is
actually
a
a
client
inside
of
this
container.
That's
running
through
Shipyard,
but
I
have
set
in
here.
I've
set
the
kuma
URL
as
a
as
an
environment
variable.
C
C
Correct
yep,
so
we
wrote
so
we
did
a
vault
right
into
the
kuma
guide
path.
That's
the
the
one
that
we
just
created,
slash
config
and
that
we've
set
the
URL
to
the
URL
and
then
the
token
to
the
Token.
This
little
amp.
This
little
Ampersand
here
means
actually
the
contents
of
a
file.
This
Kuma
token
environment
variable
is
just
a
file
like
a
link
to
a
file.
C
Yeah
see
it's
just
a
link
to
the
admin
token.
So
what
this
will
do
is
this
will
actually
take
the
contents
of
that
token
and
put
it
in
there
and
send
it
in
that's
what
that
little
Ampersand.
Does
there
all
right?
Okay,
so
now
we've
done
that.
So
now
we
have
our
configuration
set
up,
but
now
what
we
need
to
do
next
is
we
need
to
create
roles.
We
need
to
create
roles
so
that
we
can
actually
do
something
with
this
plugin.
C
So
when
you
so
in
our
plugin,
we've
created
the
ability
to
set
the
parameters
of
token
name,
mesh
and
groups
are
the
different
abilities
that
you
can
set
as
parameters
as
well
as
tags
groups
are
for
user
tokens.
So
if
you
are
a
user
and
you
want
to
interact
with
the
kuma
control
plane,
API
Services
need
the
ability
to
they
have
to
have
like
token
name
and
tags.
C
C
Yeah
so
there's
two
aspects
that
vault
maintains,
which
is
the
TTL
lease
and
the
max
TTL.
So
the
TTL,
which
is
the
lease,
is
how
long
that
token
is
good
for
until
it
will
actually
revoke
the
token
okay,
the
max
TTL
is
actually
the
lifetime
set.
In
the
token,
so
in
this
case,
I'll
give
you
an
example
down
here
where
we're
creating
this
role.
We
are
setting
the
TTL
to
one
hour,
but
we're
setting
the
max
TTL
to
24
hours,
which
means
when
we
mint
that
token
we're
only
we're
minting
the
expiration
date.
C
In
that
token,
at
24
hours,
that's
how
long
the
token
itself
is
is
good
for.
But
if
you
don't
renew
the
lease
on
this
token
within
an
hour,
then
Vault
will
actually
revoke
that
token.
It
will
go
so
in
in
Kuma.
There
is
a
a
secret
that
you
add
the
jti
to,
and
that
will
invalidate
that
token.
So,
if
you
try
to
use
that
token
and
you
haven't
revoked
your
lease,
it
actually
pulls
it
and
you
can't
use
it
anymore.
C
So
that's
actually
a
good
balance
and
Vault
agent
is
a
uses,
an
example
of
where
you
can
have
that
process
happen
automatically.
So
your
agent
requests
a
token.
Let's
say
you
set.
That
token
is
for
72
hours
as
Max
TTL,
and
then
every
you
set
your
TTL
for
six
hours.
That
would
mean
that
every
six
hours
the
agent
needs
to
go
and
refresh
the
lease
on
that
token
I
believe
the
agent
is
set
to
default
to
do
that
at
the
like
two-thirds
Mark.
C
So
once
it's
two-thirds
of
expiration,
it
will
then
so
I
think
on
a
six
hour,
it'll
be
like
about
a
four
hour
mark.
It
would
just
go
ahead
and
automatically
renew
the
lease
for
you
and
then,
when
it
gets
to
the
end
of
the
max
CTL,
you
can
set
it
to
also
where
it
would
automatically
generate
a
new
token
and
then
bump
and
rejoin.
You
know,
bump
the
the
data
plane.
C
Yeah
you
would,
you
would
configure
so,
and
this
is
where
I
would
definitely
recommend
using
for
a
service
default
agent
and
the
Vault
agent
can
actually
do
it
depending
upon
how
your
your
your
executable
at
the
time
needs
to
be
so
in
this
case
it
would
update
the
token
the
config
file.
It
would
update
the
data
plane
config
and
then
it
would
do
like
a
Sig
up
to
the
process
and
the
process
would
know
hey.
C
D
C
C
You'll
have
to
have
a
vault
token,
so
you
want
to
have
to
authenticate
with
whatever
your
authentication
I'm
already
authenticated
in
this,
and
then
you
will
need
to
then
do
a
read
on
that
admin
role
and
that
will
get
you
back
your
token
you'll
get
back
a
lease
ID.
That's
how
you
would
renew
your
release
is
with
this
this
lease
ID,
the
duration
of
the
lease.
C
C
C
We
can
do
that
here
and
you
can
see
that
we
run
that
write
the
token
out,
and
then
we
put
it
into
the
bear
when
we
do
a
curl
and
we
get
back
a
response
from
the
kuma
control
plane
on
that
specific
secret.
We
would
that
there
there
are
none,
but
that's
we're
hitting
the
control
plane
API.
With
our
token,
if.
C
All
right-
and
so
you
should
get
this
request
back
okay,
so
now
what
we're
gonna
do
is
I'm
going
to
and
I
want
to
do.
This
I
have
a
limited
amount
of
time.
I
think
I,
think
I
said
an
hour
for
those
other
services
that
I
just
booted
up
before
they
get
kicked
out.
So
all
right.
So
now
we're
going
to
go
into
the
actual
process
of
automatically
generating
as
a
service,
all
right
so
automatically
generating
tokens
for
our
data
plane,
registration,
we're
going
to
use
the
Vault
agent.
C
For
that
all
right,
you
can
go
on
the
Vault
project
and
look
at
how
that
works.
We're
going
to
be
using
April,
which
is
just
a
secret,
an
ID,
a
client
ID
and
a
client
secret
to
simulate
what
it
would
be
like
to
use
like
an
AWS,
IEM
or
any
sort
of
metadata
authentication,
and
all
of
them
are
supported
through
through
Vault.
C
So
we
need
to
create
a
role,
we're
going
to
create
a
role
right
now,
we're
going
to
register
a
payment
service
that
we're
going
to
go
through
and
do
we're
going
to
create
a
role
with
a
tag.
The
tag
is
going
to
have
that
it
is
a
payment
service,
we're
going
to
set
the
lease
for
the
TTL
to
one
hour
and
with
a
maximum
of
a
week,
and
so
this
is
how
we
would
do.
We
would
go
into
Vault.
We
would
write
into
our
guide
roles
payments
roll.
C
C
D
C
C
We're
going
to
enable
this
so
we're
going
to
a
vault
right,
we're
going
to
write
to
this
role,
we're
going
to
tell
it
the
TTL,
the
max
TTL,
the
policies
we're
going
to
give
it
both
the
default
and
the
payments
policy
and
then
find
the
secret
ID,
and
then
this
is
what
that
policy
would
need
to
look
like
involved.
This
is
a
vault
policy.
C
It's
all
path
based,
so
we're
going
to
give
the
read
capability
on
the
secrets
engine
credentials,
the
payments
role
when
you
call
the
credentials
creds,
that's
what
does
the
tells
the
plug-in
to
act,
grab
creds
all
right,
I'm,
going
to
copy
and
paste
this
one,
because
for
some
reason
it
doesn't
like
the
I'm,
sorry,
the
and
the
file
type
of
yes,
it
does
not
like
the
end
of
file
work
all
right.
So
we
should
now
have.
C
C
Okay,
so
now
we
need
to
generate
our
app
role
information.
This
is
basically
generating
our
metadata
type
stuff,
so
we're
going
to
go
ahead
and
do
that
we're
going
to
write
it
out
to
the
specific
or
no
sorry
a
lot.
We've
generated,
we've
pre-generated
our
app
roll,
ID
and
secret
we're
going
to
log
in
with
our
app
role
in
secret,
so
we're
going
to
do
Vault
right
to
the
auth
appro
login.
That's
the
method
that
you
use
to
log
into
to
Vault
with
April.
C
So
we've
done
that
now.
What
we
need
to
do
is
rather
we
can
copy
and
paste
that
all
around,
but
we
can
just
export
that
into
a
command
here.
So
we'll
run
that
that
exports
the
token
and
now
we
should
be
able
to
run
this
command
to
read
our
payments
role,
and
so
now
we
have
read
our
payments
role.
We
can
copy
and
paste
this
here
and
you
can
see
that
we
have
a
payments
service
with
the
in
the
default
mesh
and
it's
okumayo
service
patients.
Now.
C
That's
exactly
right
all
right!
So
now
that
now
we've
done
that
Okay.
So
if
you
run
this
again
so
now
we
are
logged
in
with
payment.
So
what
I'm
going
to
do
is
there's
an
existing
rollout
there
API
role
for
the
API
when
we
first
started
here,
you
have
this
API.
What
I'm
going
to
show?
You
is
what
happens
if
if
the
payment
service
tries
to
request
a
credential
for
the
API
role,
what
happens
there?
D
C
Right
now,
let's
put
this
all
together
into
the
Vault
agent,
because
this
was
we
went
through
the
manual
process
of
what
Vault
agent
is
going
to
kind
of
do
in
the
background,
but
so,
let's
actually
create
a
vault
agent.
That
will
do
this
for
us
inside
of
payments.
So
what
we're
going
to
do
is
we're
going
to
copy
and
paste
this
template.
What
this
template
is,
is
the
Vault
agent
template
it's
telling
us
that
we're
going
to
Auto
off
with
app
role
method.
You
can
use
this
to
any
type
we
can
use.
C
C
What
we're
going
to
do
is
we're
going
to
actually
with
our
secret
we're
going
to
request
the
payments
role
credential
and
we're
going
to
grab
the
data
and
the
token
element
from
that,
and
then
with
that
we
are
going
to
bootstrap
or
we're
going
to
sorry
execute
the
we're
going
to
write
that
sorry
we're
going
to
write
that
to
the
data
plane
token.
So
that's
what
we're
going
to
do
with
this
we're
going
to
take
and
we're
going
to
pull
that
write
that
out
to
the
data
plane
token.
A
C
D
C
That
is
true,
yes,
all
right.
So
now
we
have
bootstrapped
up
our
agent,
our
agent
is
running
and
it
actually
was
successful
and
execute
and
wrote
Our
token
out
now
that
we've
got
our
and
we
just
did
that
we
catted
our
token.
Now.
What
we're
going
to
do
is
we're
going
to
start
the
kuma
control
plane
with
the
token
that
we
just
ran,
so
let's
go
ahead
and
do
that
we
are
going
to
join
and
we're
going
to
leverage
that
token
to
join
our
control
plane.
C
B
That's
pretty
cool,
so
all
right
in
for
the
future
Services.
What
kind
of
stuff
needs
to
be
happening,
so
we
need
to
create
the
policy
in
order
to
this
service
will
be
able
to
use
a
apis
to
generate
token
right,
correct.
So,
for
example,
we
have
another
service
order
service.
We
need
to
have
a
policy,
so
this
service
will
be
able
to
request
or
get
access
to
to
generation
of
these
tokens.
C
There's
a
user
token,
revocation
and
there's
a
service,
token
revocations
and
then
the
service
token
revocations
is
under
the
mesh,
so
it
would
be
under
the
default
mesh.
So
when
you
Revo
in
order
to
revoke
those
tokens,
you
actually
have
to
just
it's
basically
a
comma
separated
list
inside
of
that
secret
of
all
the
jtis.
So
once
you
put
the
jti
anytime,
someone
tries
to
authenticate.
With
that
token
they
instantly
get
revoked.
There's
not
a
cleanup
process
right
now
in
in
Kuma,
but
we
actually
added
that
into
the
Vault
plug-in.
So
what
happens?
C
Is
you
know?
You
have
that
TTL
and
Max
TTL
when
you,
when
the
max
TTL
expires,
it
will
actually
Vault
will
actually
go.
Read
the
the
secrets
list
and
actually
pull
the
jti
out,
because
now
that
that
that
token
has
expired
and
is
no
longer
eligible
to
be
used
anyway,
so
it
actually
will
Auto
keeps
the
keeps
the
seek.
The
revocation
list
clean
by
using
the
Vault
plug-in
so
yeah,
and
if
you
want
to
play
around
this
specific
page
in
the
documentation,
shows
you
how
to
set
up
a
short
TTL
lifetime.
C
D
B
B
Let
me
quickly
check
the
chat
and
see
if
they
have
any
other
questions.
There's
always
good
praise
to
get,
and
some
people
actually
want
to
return
and
rewatch.
This
later,
that's
that's
going
to
be
that's
going
to
be
good
stuff
to
to
learn
so
with
with
this
I
think
Gregor.
Do
you
have
any
like
a
preferred
way
if
people
want
to
contact
with
you
and
talk
to
you
about
you
probably
mentioned
this
like
GitHub
would
be
right
place
to
start
talking
right.
C
Definitely
yep
so
you
can
go
to
my
GitHub
is
just
github.gregoryhunt.com.
The
demo
is
on
the
demo,
Dash
Kuma
Dash
Vault,
that's
what
we
just
went
through
today.
You
can
literally
pull
that
down
and
as
long
as
you
at
install
Shipyard,
you
can
literally
walk
through
everything
we
did
today
through
that
exact,
same
interactive
documentation
and
play
around
with
it
all
you
want,
and
then
the
actual
plugin
itself
is
on.
C
This
is
in
my
same
GitHub
under
Vault
Dash,
plugin
Kuma,
there's
already,
we've
got
some
planned
enhancements
that
we're
going
to
be
adding
to
it.
One
of
those
is,
is
the
secrets,
so
the
auto
the
root
root,
auto
root
rotation,
which
is
what
will
happen,
is
right
now,
when
you
add
that
admin
token
in
there
that
admin
token
lives
for
a
certain
period
of
time.
C
What
we're
going
to
do
is
we're
going
to
add
there's
a
another
interface
inside
of
the
plug-in
The
Vault
plug-in,
which
allows
us
to
actually
have
the
system
generate
its
own
new
admin
token.
So
what
you
can
do
is
when
you
bootstrap
vault,
to
begin
with,
you
use
a
short
list
of
token
like
five
minutes,
then
you
rotate
the
root
secret.
It
generates
its
own
new
secret,
which
you
could
have
before
a
month
or
a
year
and
then
it'll
continue
to
do
that,
and
no
human
will
ever
know
that
secret
anymore.
C
B
Exactly
exactly
so,
that
was
pretty.
That
was
pretty
pretty
nice,
and
so
now
you
have
it
folks.
So
you
now,
you
understand,
there's
a
some
of
the
deep
insights
that
happening
inside
the
the
kuma
and
how
the
kuma
integrates
with
the
services
on
top
of
it
all.
Obviously,
you
also
can
put
the
you
know,
mtls
and
all
this
kind
of
things,
but
in
order.
A
B
C
B
We
do
have
we
do
have
this
integration
in
the
quantum
mesh,
with
the
with
Revolt
as
a
CA
as
a
reminder,
so
Kuma
is
in
CF
open
source
project
and
it
called
we
actually
building
some
of
the
additional
features,
maybe
like
some
of
the
deep
Cloud
integration
that
we
did
for
I
guess
for
AKs
and
everything.
So,
let's
build
some
automation
for
for
for
Kuma,
and
this
is
kind
of
like
a
commercial
product
but
is
available
as
a
you
know.
B
The
trial
can
always
request
a
license
to
play
around
and
see
if
the
Conch
mesh
is
something
that
you're
interested
in
or
you
know
who
might
would
be
solving
all
your
problems.
I
would
like
to
say
thank
you
huge
thanks,
Gregory
for
first
of
all,
speaking
at
the
Kong
Summit,
it's
a
it's
a
huge.
You
know
time
to
prepare
and
develop
this
plugin
and
I
see
he's
wearing.
D
B
Kong
Champion
t-shirt
as
the
recognition.
This
is
what
try
to
recognize
and
say
thanks
to
the
people
who
contribute
back
to
to
our
community,
it's
great
to
have
him
on
the
live
stream,
write
down
in
the
comments
into
this
into
the
streams
and
recordings
we
do
have
one
quick
question,
so
let
me
see
if
I
will
be
able
to
add
this
to
broadcast.
So
let
me
try
to
see
if
I
will
be
able
to
make
this
slightly
smaller,
so
it
will
fits
the
fits
the
screen.
Okay,
that's
that's!
A
C
C
Yeah
and
that's
one
of
the
things
where
you
know
generally:
it's
not
as
good
practice
to
keep
if
you
can
keep.
If
you
can
keep
your
tokens
out
of
in
files,
because
m-files
can
easily
get
committed
right
and-
and
that's
where
we're
talking
about
so
then
you
can
commit
your
tokens
and
then
you
have
to
completely
invalidate
those
and
and
generate
new
ones
or
someone
can
get
access.
So
you
know
using
this
more
dynamically
generated,
it's
going
to
be
rotating
the
tokens
and
and
you're
going
to
have,
even
if
they
accidentally
got
committed.
C
B
Yeah,
and
this
is
our
queue-
this
is
our
cue
that
we
are
done
for
today.
I
would
like
to
remind
you
that
all
the
things
that
we
described
here
you
can
find
in
the
description
below
sign
up
for
new
episodes
of
Kong
Builders,
and
with
this
my
name
is
Victor
gamof
and,
as
always,
have
a
nice
day.
I'll
see
you
in
the
next
one.