►
From YouTube: Cloud Native Live: Certificate management with Linkerd
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi,
everyone
welcome
to
cloud
native
live
where
we
dive
into
the
code
behind
cloud
native,
I'm
annie
and
I'm
a
cncf
ambassador
as
well
as
a
senior
product
marketing
manager
at
camunda,
and
I
will
be
your
host
tonight.
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
native
technologies.
A
They
will
build
things,
they
will
break
things
and
they
will
answer
all
of
your
questions
so
join
us
every
wednesday
to
watch
live
so
this
week
we
have
lin
here
with
us
to
talk
about
certificate
management
with
linkerdy
and
as
always,
this
is
an
official
live
stream
of
the
cnc
app
and
as
such,
it
is
subject
to
the
cncf
code
of
conduct.
So
please
do
not
add
anything
to
the
chat
for
questions
that
would
be
in
violation
of
that
code
of
conduct.
B
Hi
there,
so,
yes,
I
am
flynn,
I'm
a
tech
evangelist
for
buoyant
working
with
linkery.
These
are
some
ways
that
you
can
reach
me
the
best
one's,
probably
the
slack
link
at
flynn
on
the
linker
d
slack.
You
can
also
tweet
it
boy
enter,
find
me
on
github.
If
you
really
need
to
I'm
not
sure
why
you
would.
This
is
a
workshop.
B
We
do
have
a
bit
of
background
first,
since
we're
talking
about
certificates
and
teal
and
all
this
kind
of
stuff,
but
we
are
going
to
be
spending
most
of
the
time
going
through
doing
hand
on
either
working
a
demo
or
breaking
things
we'll
find
out
which
tools
that
you
need.
If
you
want
to
follow
along
from
home-
and
I
hope
you
do-
you
would
need
a
clear
with
the
coop
control
command,
I'm
going
to
be
using
a
k3d
cluster.
B
It
doesn't
really
matter
what
kind
of
cluster
you're
using
as
long
as
you
have
one
we
will
be
doing,
we
will
be
using
linker
d.
You
can
get
that
from
linker
dot,
io
we'll
be
using
the
step.
Cli.
Sorry,
the
linker
dcli
in
particular.
You
will
need
that.
You'll
need
the
step
cli
from
smallstep.com,
we're
going
to
use
that
to
manipulate
certificates
and
you'll
need
the
help
of
cli,
because
we're
going
to
use
helm
to
install
cert
manager
later
on.
B
B
It's
a
very
simple
idea:
instead
of
having
one
key
that
you
use
for
encryption
and
decryption,
you
have
a
key
pair,
you
have
a
public
key
and
a
private
key.
These
two
keys
are
linked
mathematically
with
a
few
properties,
in
particular.
The
first
one
is
anything
that
you
encrypt
with
the
public
key.
You
must
have
the
private
key
to
decrypt.
B
Conversely,
if
you
encrypt
something
with
a
private
key,
you
must
have
the
public
key
to
decrypt
it.
And
finally,
if
you
only
have
the
public
key
recovering,
the
private
key
is
impossible.
The
air
quotes
are
there,
because
if
you
want
to
get
technical,
it's
merely
astronomically
unlikely
in
practice
not
going
to
happen.
B
These
three
properties
give
rise
to
some
really
interesting
aspects
of
public
key
crypto.
The
first
one
is:
if
alice
will
encrypt
some
data
with
bob's
public
key.
Only
bob
will
be
able
to
read
that
data,
because
bob
is
the
only
one
that
has
bob's
private
key
like
as,
if
alice
were,
to
encrypt
something
with
her
own
private
key.
Then
only
she
could
have
written
that
because
she's,
the
only
one
with
her
private
key,
this
business
of
encrypting
with
your
own
private
key
by
the
way,
is
actually
really
common.
B
So,
given
all
of
that
stuff,
a
couple
of
things,
one
is
the
private
keys
have
to
be
kept
private
and
they
form
the
basis
of
identity.
If
only
one
person
has
the
private
key,
and
we
can
verify
that.
It
really
is
that
private
key
that
did
something.
That's
a
good
proxy
for
identifying
the
person
holding
that
key.
B
Conversely,
keys
can
and
really
should
be
shared
with
everybody,
because
the
more
people
that
have
them
the
easier
easier
it
is
to
do
verification
of
identity,
and
both
of
these
things
are
important.
Also,
the
more
widely
say
bob
shares
his
public
key,
the
easier
it
is
for
alice
to
get
it
and
send
him
some
data,
and
that's
really.
B
Mtls
happens
to
rely
on
this
at
linkedin.
Authentication
ultimately
relies
on
mtls.
All
this
stuff
is
is
important.
It's
also
worth
pointing
out
that
one
of
the
interesting
problems
here
is
we're
using
a
private
key
as
the
root
of
identity,
but
we
haven't
really
talked
about.
Okay.
How
do
you
manipulate
the
private
key?
How
do
you
share
the
public
keys
to
make
all
of
this
work?
That
leads
us
into
the
world
of
certificates,
which
are
usually
the
everybody
who's
trying
to
work
with
anything
with
public
key
but
they're
also
fairly
simple.
B
A
certificate
is
a
data
structure
that
takes
a
key
pair
and
associates
a
name
with
it.
The
name
is
called
a
subject.
The
association
is
done
via
a
signature
so
that
you
can
know
that
this
identity-
this
name,
really
does
belong
to
this
particular
key
pair
certificates
only
contain
public
information,
so
they
are
safe
to
share.
B
This
is
important.
You
have
to
share
them,
people
to
be
able
to
use
them.
The
signing
again
prevents
them
from
being
spoofed
which
allows
them
to
be
trusted
for
identity
and
we're
going
to
talk
quite
a
bit
more
about
the
whole
manner.
In
which
they
are
signed,
but
there's
also
a
last
bit
here,
which
is
rotation,
there's
a
basic
axiom
in
cryptography
that
the
longer
you
use
a
given
key,
the
more
risk
you've
piled
up
with
that
key
and
the
more
attractive
it
becomes
for
an
attacker
to
try
to
steal
it.
B
Of
course,
if
you're
changing
the
private
key
and
we're
using
the
private
key
as
the
basis
of
identity
that
creates
kind
of
an
interesting
problem
that
gets
solved
by
having
the
signer
of
the
key
stay
the
same
as
you're
rotating
the
key
underneath
it.
But
rotation
is
a
very
important
thing.
This
is
one
of
the
things
we're
going
to
look
at
in
the
workshop
is
how
you
rotate
keys
with
lingerie,
and
it's
important
that
you
do
it
periodically.
B
B
B
The
immediate
reason
why
we
don't
just
have
one
layer
of
signing
here
is
that
this
way
we
can
rotate
the
issuer
certificates
very
often
without
having
to
do
anything
with
the
trust
anchor.
Also,
the
workloads
get
to
use
the
workload
certificates
to
protect
calls
from
workload
to
workload,
but
by
having
multiple
issuer
certificates.
B
We
also
get
to
separate
this
completely
from
the
topology
of
the
network
so
that
you
can
have
workloads
that
might
even
be
in
different
clusters.
As
long
as
there
is
a
relationship
with
the
trust
anchor,
then
this
works
fine
and
workload.
Two,
for
example,
can
just
use
worklist
workload,
three's
private
public,
key
to
encrypt
data,
sent
to
workload
three
workload,
two
consignment
with
workload,
two's
private,
key
workload:
three:
you
can
use
the
public
key
for
workload,
two
to
verify
everything
and
it
all
works.
None
of
this
relies
on
the
topology
of
the
network.
B
B
Okay,
so
with
that
in
mind
I
mentioned
we
can
use,
we
can
easily
rotate
the
identity,
the
issuer
certificates
without
having
to
mess
with
the
trusted
anchor,
so
that
permits
us
to
rotate
the
identity
issuer
certificates.
Very
often,
there's
a
trade-off
to
be
made
here.
If
you
rotate
certificates
quickly,
it
limits
your
risk,
because
if
a
certificate
gets
compromised,
it
will
be
compromised
until
at
least
the
next
rotation.
B
There
are
two
really
really
big
counterpoints
here.
One
is,
if
you're
rotating
the
certificates
more
often
you're
going
to
be
spending
more
of
your
time,
messing
with
certificate
rotation.
B
B
B
It's
just
a
balance
that
you
have
to
strike
for
any
particular
application
that
you're
working
on
okay
workshop
time
again,
I
encourage
you
to
follow
along
there's
the
url
for
the
repo
that
I'm
working
out
of
you'll
be
able
to
see
this
stuff
in
the
l5d
certificate
management
directory
and
the
service
mesh
academy,
repo
and
again
we're
going
to
be
using
the
steps
cli
we'll
be
using
helm,
we'll
be
using
cert
manager
and
we'll
be
using,
of
course,
the
linker
d.
Cli.
A
You
clearly,
if
there's
any
quick
fixes
to
be
done,
we
could
try
those,
but
I
think
well.
B
I
guess
we'll
see
if
this
gets
any
better
yeah.
I
guess
we'll
see
if
it
gets
any
better,
so
fingers
crossed
all
right
in
the
workshop,
we're
going
to
cover
a
few
things.
There's
the
basic
skill
of
generating
and
inspecting
certificates,
using
the
step,
cli
we're
going
to
do
a
staging
setup
where
we
create
a
self-assigned
trust
anchor
and
then
use
it
to
create
the
other
certificates
to
get
linkedin
running.
B
We're
going
to
talk
about
the
operational
skill
of
rotating
kits
and
then
we're
going
to
do
a
production
setup
where
we
bootstrap
all
this
stuff
with
cert
manager
to
make
life
easier
on
us.
The
people
who
are
trying
to
get
work
done
for
homework
you'll
get
to
fully
automate
the
identity
with
cert
manager.
We're
just
going
to
do
the
bootstrapping,
because
once
it's
bootstrapped
going
to
fully
automated,
is
usually
a
lot
easier.
B
So,
let's
get
to
it
and
you
get
a
free
look
early,
look
at
the
cooker
thing
which
you
should
sign
up
for,
but
we'll
come
back
to
that
later.
Okay,.
A
A
B
Excellent,
okay,
so
basic
skill:
how
do
you
use
step
to
generate
and
inspect
a
certificate?
First
thing
to
remember
here
is
that
step
dash,
dash
help
is
easy
and
useful
and
gives
you
a
lot
of
good
information,
so
here's
the
basics
for
generating
a
certificate.
This
looks
a
lot
uglier
than
it
really
is
we're
going
to
break
all
this
down
a
little
bit
later,
but
this
is
the
name
that
goes
into
the
certificate.
B
This
tells
us
what
kind
of
certificate
we're
going
to
create.
This
example
is
showing
a
route,
the
basically
a
trust,
anchor
the
thing
at
the
root
of
a
certifying
authority
that
can
be
used
to
sign
other
certificates,
and
these
are
things
that
are
important
for
demos
and
not
necessarily
a
great
idea
in
practice.
They
are
saying
that
they,
you
don't
want
to
protect
this
cert
with
a
password,
and
you
know
that
that's
insecure,
because
it
is,
but
that's
what
we're
going
to
do
just
so,
we
can
go
ahead
and
get
this
going.
B
It
generates
it
quickly.
It
saves
it
if
we
try
to
just
look
at
this
certificate.
It's
kind
of
useless.
This
is
what
the
step
certificate
inspect
command
is
for.
If
we
use
this,
we
see
a
bunch
of
things
again
we're
going
to
break
this
down
a
little
bit
later,
but
some
particular
things
are.
You
can
actually
see
the
public
key.
You
can
see
a
signature
that
was
made
with
the
private
key.
B
B
Root.Linkerd.Cluster.Local
must
be
the
name
that
you
use
for
a
link
or
d
trust
anchor
we're
going
to
save
these.
The
public
half
interest,
anchor
dot,
crt
the
private
half
interest
anchor
dot
key
again
we're
going
to
pick
the
root
ca
profile
again,
no
password
insecure
and
we're
going
to
make
this
not
expire
until
st
patrick's
day
of
2060.
B
B
B
It
is
valid
not
after
march
17th
of
2016..
The
other
thing
here
is
it's
okay:
to
use
this
to
sign
certificates,
it's
okay!
To
use
this
to
sign
certificate,
revocation
lists,
which
is
a
particular
kind
of
thing
that
you
can
use
to
spread
around
to
the
world
and
say
hey,
I
have
found
a
certificate
that
was
compromised,
don't
trust
it
anymore.
B
A
B
B
B
What
is
critical,
excellent?
Let
me
come
back
to
that
when
we
inspect
this
certificate,
this
one
is
expiring
in
2050,
it's
important
to
note
that
in
general
you
want
you
want
the
issuer
certificates
to
expire
before
the
trust
anchor
does.
The
reason
for
this
is
that
it's
much
easier
to
rotate
the
issuer
certificates
and
they
tend
to
have
to
have
their
keys
live
in
the
cluster,
so
it's
also
more
important
to
rotate
them
more
frequently.
B
B
We
don't
usually
have
to
worry
about
that
too
much,
because
the
tooling
that
you
work
with
like
step
knows
how
to
interpret
these
things
and
it
won't.
Let
you
do
something
that
would
violate
a
critical
constraint,
but
that's
really
going
on.
Can
I
ask
what
tool
you
use
to
speed
the
command
on
the
terminal?
In
fact,
you
may
it's
a
thing
called
demomagic.sh
and
I'll
make
sure
there's
a
link
to
it
in
the
repo.
B
I
love
it
big
fan
of
it.
Okay,
so
now
we're
going
to
use
the
certificates
that
we
just
made
to
install
linker
d
first
up
need
a
cluster
to
install
linkerd
into.
I
am
using
a
single
node
k3ds
cluster
just
running
locally
on
my
mac.
Should
all
work
pretty
much,
no
matter
what
kind
of
cluster
you
have.
So
you
know
you
do
you
for
whatever
cluster
you
want.
B
We
also
need
to
know
that
this
cluster
is
actually
capable
of
running
linkery.
The
linker
dcli
has
a
command
that
makes
this
very
easy.
You
can
run
check,
dash,
dash,
pre
and
it'll
go
through
and
do
all
of
the
checking
to
make
sure
that
we
have
a
cluster
that
we
can
go
and
install
linkery
on,
and
everything
is
good.
We
get
green
check
marks
across
the
board.
This
is
what
we
want
to
see
so
now
this
bit's
important
for
people
have
used
lingerie
before.
B
As
of
last
night,
linker
d
2.12
is
out
that's
what
I'm
using
here
in
linker
d,
2.12,
there's
an
additional
step
when
you're
doing
installation.
You
have
to
explicitly
install
the
crds
by
hand
now
because
crds
are
getting
more
complicated,
complicated
to
wrangle.
So
let's
do
that
we'll
go
ahead
and
install
the
crds
okay.
B
One
other
note
we
hand
in
the
trust
anchors
public
key,
but
we
don't
say
anything
about
the
trust
anchors,
private
key
and
the
trust
anchors.
Private
key
is
actually
never
going
to
be
in
the
cluster
at
all,
because
the
trust
anchor
is
used
for
verification.
It
does
not
have
to
sign
anything.
It
does
not
need
access
to
its
public,
its
private
key.
So
it's
much
better
to
not
have
it
in
this.
The
cluster
at
all
keeping
it
out
of
the
cluster
is
safer.
B
Sorry
there's
a
question
here
because
it's
manual
install
cause
which
I'm
missing
some
context
for
that
question.
I'm
sorry.
A
No
worries
kenneth
if
you
can
provide
a
bit
more
context,
we'll
get
the
question
answered.
Yeah.
B
Yeah
and
in
the
meantime,
we'll
start
linkery
installing,
because
this
next
bit,
where
we
run
liquor
d
check
to
make
sure
that
linkery
is
up
and
running.
B
A
Of
time
to
type
more
context
in.
A
B
B
So
from
kenneth
the
ca
it
was
manual,
so
you
flip
to
the
fuller
command.
Exactly
if
you
don't
use
those
arguments
on
linkedin,
install
linker
d
actually
generates
temporary
certificates
for
you,
and
this
works
great,
but
in
this
particular
case,
where
we
want
control
over
it,
and
we
want
to
do
our
own
certificate
rotation
and
we
basically
we
want
the
whole
thing
in
our
hands,
so
we
have
to
explicitly
tell
lingerie
these
are
the
certificates
you
use?
B
Also,
if
you
use
helm
to
install
linker
d,
you
always
have
to
supply
their
certificates,
so
you
have
to
generate
them
on
your
own.
So
hopefully
that
answers
that
question.
We
have
green
check
marks
across
the
board
again,
so
we
are
actually
have
a
running
liquidy,
which
is
great
now
in
the
real
world.
We
would
then
go
through
and
set
up
some
workloads
and
get
them
into
the
mesh,
and
you
know
test
our
applications
and
we're
going
to
skip
all
that,
because
this
particular
one
is
talking
about
certificate
management,
not
workload
management.
B
It's
really
just
even
for
staging
cluster.
That
would
be
too
long
for
me
to
really
be
comfortable
with.
So
what
we're
going
to
do
here
is
generate
new
ones
which,
with
much
shorter,
expirations
and
then
we'll
use
those
to
demo
how
you
rotate
new
things
in
let's
see
a
couple
of
points
to
remember
here
is:
it
can
be
really
really
difficult
to
actually
know
when
a
key
gets
compromised,
especially
in
the
kubernetes
world.
So
you
do
better
to
err
on
the
side
of
assuming
that
compromises
can
happen
more
often
than
you
probably
think.
B
This
means
that
the
issuer
certificates
are
at
significantly
greater
risk
than
the
trust
anchor
and
in
turn,
that
means
that
rotating
issuer
certificates
fairly
often
is
a
really
good
idea,
especially
in
production.
We
also
mentioned
briefly
the
crl
the
certificate
revocation
list
certificates
can
get
revoked.
B
This
is
probably
a
little
bit
more
common
in
enterprise
worlds,
where
maybe
your
trust
anchor
is
being
given
to
you
by
your
corporate
security
people.
It's
a
little
bit
less
likely
to
happen
if
you're
doing
this
all
by
hand
in
a
five
person
startup,
but
still
it
can
happen
and
it's
better
to
get
accustomed
to
actually
rotating
certificates
and
treating
them
with
some
care.
So
let's
go
ahead
and
do
that.
B
We're
gonna
generate
a
root
ca
with
a
validity,
not
a
valid
t.
Oh
dear
a
validity
of
two
months,
one
thousand
four
hundred
forty
hours
and
we'll
generate
an
issuer
with
a
validity
of
one
week,
168
hours
again,
there
are
no
hard
and
fast
right
answers
for
how
long
is
too
long
or
too
short.
B
B
B
So
let
me
answer
this,
assuming
that
your
daily
generated
self-signed
certs
are
for
one
of
the
linker
d
or
for
one
of
the
certificates
in
the
lingerie
world.
If
you
want
to
use
a
self-signed
certificate
that
you
rotate
every
day
as
your
trust
anchor,
everything
will
work.
Great
and
you'll
see
the
process
for
doing
that
in
a
minute.
B
B
I
expect
you're,
probably
not
trying
to
use
it
as
a
workload
certificate,
but
if
you
are,
it
would
have
to
be
signed
by
the
issuer
certificate,
and
if
that
doesn't
answer
your
question,
then
let
me
know
if
it's
not
part
of
the
the
linker
d
trust
chain
from
the
trust
anchor
to
the
issuer,
to
the
workload
cert
and
it's
just
some
other
certificate
that
your
application
needs
to
use
to
hand
off
to
a
browser
or
whatever
you're
golden
you
don't
need
to
have
that
signed
by
anything,
in
particular
from
lingardy's
point
of
view.
B
Your
the
rest
of
your
application
may
have
its
own
demands,
of
course,
okay.
So
this
is
pretty
much
exactly
the
same
command
that
we
did
to
generate
the
first
trust
anchor.
We've
changed
the
names
of
the
files
and
we've
changed
the
not
after
argument,
so
we
do
those
we
can
pay
attention
to
validity.
B
Now
it's
not
valid
after
october
23rd
of
2022,
which
is
you
know,
considerably
more
reasonable.
We
can
then
use
our
new
trust
anchor
to
generate
a
new
issuer
certificate
and
once
again,
we've
changed
the
file
names.
We've
changed
the
trust
anchors
file
names
for
the
signature
and
again,
we've
changed
not
after
if
we
inspect
that
one.
B
If
we
inspect
that
one
with
the
wrong
file
name,
then
we'll
still
see
the
2050
expiration
date.
If
we
were
using
the
correct
thing,
we
would
find
that
it
was
out
on
august
31st,
so
we're
just
gonna
pretend.
B
Okay
yeah,
they
say
to
never
precede
a
software
demo
with
any
comment
more
predictive
than
watch
this.
So
this
is
why
all
right,
so
talking
about
rotating
certificates,
we've
just
added
a
bunch
of
security
by
having
these
things
expire
in
two
weeks,
instead
of
you
know,
30
years,
almost
this
means
that
we
have
to
pay
a
lot
more
attention
to
rotating
them.
We
must
rotate
certificates
before
they
expire.
Repeat
after
me,
I
will
rotate
my
certificates
before
they
expire.
This
is
very,
very
important.
B
B
You
might
also
you
know-
maybe
the
corporate
id
people,
the
corporate
security
people,
have
handed
down
your
shiny,
new
trust
anchor
from
on
high,
and
you
need
to
replace
it
same
thing.
When
you
talk
about
rotating
a
certificate
that
really
means
replacing
it.
The
actual
process
you
have
to
follow
varies
depending
on
which
certificate
you're
talking
about
rotating.
B
If
you
rotate
the
trust
anchor,
that's
the
hardest
one,
because
you
have
to
rotate
the
trust
anchor
and
then
rotate
all
the
issuers
and
then
let
them
do
all
the
leave
certificates.
If
you
want
to
do
the
issuer
certificates,
you
can
do
them
without
touching
the
pro
the
trust
anchor
and
the
workload
or
leaf
certificates.
B
Honestly,
you
shouldn't
have
to
worry
about
it
all,
because
that's
part
of
linkard's
job,
so
the
first
thing
that
you
always
want
to
do
here
is
to
check
the
state
of
the
world,
and
here
once
again,
linker
d
check
comes
into
play.
This
is
the
dash
dash
proxy
argument
to
tell
it
that
you're
going
to
focus
specifically
on
the
proxy
layer,
the
data
plane.
B
B
This
is
a
warning
because
you
may
very
well
have
time
to
fix
this
without
incurring
downtime.
All
you
have
to
do
is
rotate
the
certificate
before
you
actually
get
to
the
expiration
if
you
actually
do
get
to
the
expiration.
This
is
the
one
you'll
see
you
don't
want
to
see
this.
This
is
a
pain,
your
cluster's,
probably
not
working
anymore,
and
you
have
to
go
through
and
replace
all
the
certificates,
starting
from
the
trust
anchor
all
the
way
down.
So
again,
don't
get
there
keep
an
eye
on
your
trust
anchor.
B
B
B
B
So
we
would
start
by
generating
a
new
trust
anchor
we're
not
actually
going
to
run
that
in
this
particular
case,
because
a
few
minutes
ago
we
generated
a
60-day
trust
anchor
that
we
can
use.
B
The
reason
we
need
to
do
this
is
that,
right
now,
at
this
very
moment,
the
issuer
certificates
in
my
cluster
are
signed
by
my
old
trust
anchor.
If
I
just
swap
out
the
trust
anchor
entirely,
my
cluster
will
stop
working
because
the
issuers
are
no
longer
valid
because
they
are
no.
They
no
longer
have
a
valid
signature.
B
Is
there
a
way
to
generate
a
trust
anchor
from
the
certificates?
It
needs
to
be
a
okay.
Let
me
back
that
up.
B
B
But
if
those
constraints
are
true,
you
can
just
stuff
it
in
as
your
trust
anchor
and
then
follow
the
rest
of
this
rotation
and
it'll
be
fine.
So
hopefully
that
answers
that
in
the
meantime,
we're
actually
going
to
read
the
current
trust
anchor
out
of
the
cluster.
B
This
is
the
way
that
you
can
make
absolutely
certain
that
you're
working
with
the
correct,
original
trust
anchor
remember
certificates
are
only
public,
it's
perfectly
safe
for
them
to
be
in
the
cert
and
it's
perfectly
safe
to
pull
them
off
and
write
them
to
the
file
system,
so
we'll
grab
that
we
can
expect
inspect
that
just
to
show
that
it
really
is
a
certificate
and
it's
really
the
old
one.
This
is
the
last
time
I'm
gonna
bother
inspecting
one
though
it
is
a
certificate.
B
B
There
we
go
and
then
we
will
deploy
that
bundle
as
our
new
trust
anchor
back
into
the
cluster
cross.
Your
fingers
hey
there.
We
go
all
right
if
we
were
doing
this
in
the
real
world.
This
would
be
the
point
where
you
would
need
to
restart
all
of
your
meshed
workloads,
because
if
you
were
to
run
link
rd
proxy
check,
sorry
linkery
check
proxy
right
now
before
restarting
any
of
the
meshed
workloads.
B
B
B
B
Actually,
before
we
go
there,
I
don't
see
any
other
questions
all
right,
so
we've
rotated
the
trust
anchor.
Now
we
have
to
rotate
the
certificate,
the
issuer
certificates.
B
At
this
point,
everything
it
will
be
using
the
trust
anchors
that
have
been
updated.
Nothing
should
still
be
using
the
old
trust
anchor,
so
it's
safe
to
get
rid
of
it.
So
we
do
exactly
the
same
thing
as
rotating
our
trust
anchor,
but
instead
of
feeding
at
the
bundle
we
feed
it
only
the
new
certificate.
B
B
B
Actually,
you
know
what
I
lied.
The
next
step
is
for
me
to
go
through
and
and
read
this
bit.
This
is
actually
you
know
this
is
relevant
right.
Every
time
you
have
to
replace
the
trust.
Anchor
you're
gonna
have
to
replace
the
issuer
afterwards,
and
there
are
three
distinct
steps
to
all
this
one.
First,
you
have
to
update
with
the
bundle
that
has
both
the
old
trust
anchor
and
the
new
trust
anchor.
B
B
All
right
and
now
is
the
point
where
we
talk
about
rotating
expired
certificates.
If
you
let
your
certificate
expire,
any
of
these
certs
expire.
B
If
you
manage
to
avoid
downtime,
it's
blind
luck,
so
don't
let
yourself
get
into
that
situation
you
basically,
if
only
the
issuer
certificate
has
expired.
It's
not
that
bad!
You
just
do
a
rotation,
because
if
your
trust
anchor
is
still
valid-
and
you
still
have
its
private
key,
you
can
just
generate
a
new
issue-
a
certificate
signed
by
the
trust,
anchor
rotate
it
in
and
all
will
be
well.
B
B
B
B
B
A
reasonably
good,
pki
setup
will
be
able
to
handle
both
bootstrapping
identity
and
a
brand
new
cluster
and
automatically
rotating
certificates
for
you.
Cert
manager
can
do
both
since
we're
kind
of
pushing
on
time
a
little
bit.
We're
only
going
to
show
the
bootstrap
step
here,
setting
up
automatic
rotation
once
you
have
identity.
Bootstrapped
is
both
a
good
learning
exercise
and
usually
pretty
easy.
So
we're
going
to
leave
that
one
as
homework
as
far
as
bootstrapping.
B
Linker
desert
management
with
jet
stacks.
How
do
I
compare
linker
desert
management
with
jet
stacks
cert
manager?
I
am
about
to
be
installing
jet
stacks
cert
manager,
linker,
d's
certificate
management,
they're,
they're,
complimentary,
they're,
not
competitors,
linker,
d's,
job
really
centers
on
those
workflow
certificates.
They're.
B
Sorry,
the
workload
certificates
out
at
the
leaves
of
the
graph,
so
that
linker
d
can
make
good
decisions
about
what
it
should
allow
or
not
allow
when
one
workload
is
talking
to
another
cert
manager
is
all
about
the
problem
of
managing
rotation
of
certificates,
which
linker
d
other
than
the
work.
The
workload
search.
Linker
d
doesn't
worry
about
that
at
all.
It
assumes
that
you're
going
to
want
to
set
something
up
where
that's
their
core
thing:
that's
their
core
competency,
rather
than
competing
with
it.
We'd,
rather
just
work
with
them.
Does
that
answer
the
question?
B
Hopefully,
if
not,
let
me
know-
and
in
fact
as
mentioned,
I
am
going
to
install
cert
manager
right
now,
so
we
make
sure
we
have
the
repo
and
then
these
are
pretty
much
straight
out
of
the
out
of
the
quick
start
for
cert
manager,
where
we
just
go
through
and
install
the
cert
manager
home
chart.
B
It's
pretty
a
little
light.
Jazz
that'd
be
good,
we're
also
gonna
install
jet
jet
stacks
trust
tool.
Basically,
it
makes
it
easier
for
us
to
tell
jet
stack
exactly
how
we
want
the
trust
hierarchy
to
be
set
up
within
the
within
the
cluster
all
right
now.
B
This
next
bit
gets
a
little
bit
odd.
We're
going
to
go.
Look
at
a
bunch
of
the
crds
underneath
this
configuration
we're
not
going
to
talk
too
much
about
them,
because
they're
going
to
be
pretty
much
the
same
for
most
linkedin
installations,
but
the
core
of
what
we're
going
on
here
is
that
there's
a
config
map
called
linkery
identity,
trust
routes
that
must
have
the
trust
anchor
in
it
and
there
we
need
a
secret
that
will
hold
the
issuer
certificate
later.
B
So,
let's
take
a
look
at
some
crds
to
make
cert
manager
do
that
to
set
up
the
trust
anchor
we're
going
to
ignore
a
lot
of
this
but
critical
bit.
Remember
that
common
name,
root.linkerd.cluster.local!
B
B
To
set
up
well
actually
we'll
go
ahead
and
apply
that
one,
and
we
can
see
that
cert
manager
has
in
fact
made
us
a
secret
for
the
trust
anchor
don't
mount
this
in
a
pod
or
in
general,
don't
give
it
any
way
to
go
through
and
and
be
visible
from
inside
your
certificate.
Let
cert
manager
worry
about
that.
B
This
actually
contains
the
trust
roots
secret
key,
because
cert
manager
can't
do
its
thing
without
the
trust
roots.
The
trust
anchors
c
secret
key,
but
you
really
really
don't
want
things
poking
at
that
when
they
don't
need
to.
This
is
in
the
cert
manager
namespace,
so
you
know
set
up
our
back
so
that
other
people
can't
look
at
it
and
don't
mount
it
in
a
pod
or
anything
crazy
like
that.
B
So
next
up
the
identity
issuer
and
again
you
know
raw
crds,
where
here's
the
name,
the
the
name
that
we
used
earlier
identity.linkerd.cluster.local
and
we're
going
to
go
through
and
set
that
up.
B
Sorry
that
secret
name
was
given
up
here
and
then
the
last
bit
is
that
we
have
to
go
through
and
set
things
up
to
link
this
back
to
the
to
the
config
map
and
chain
everything
together
in
terms
of
the
trust
hierarchy.
I'm
not
really
going
to
break
this
down.
It's
kind
of
more
of
the
same.
Where
you'll
see
these
things
and
you'll
see
that
we're
looking
at
these
secrets
and
all
that
so
we'll
apply
that.
B
B
If
this
turns
all
green,
we
will
know
that
cert
manager
actually
did
its
thing
and
set
up
shiny,
new,
shiny,
new
trust,
anchor
and
issuer
cert,
and
all
that
for
us
and
if
it
doesn't
turn
green,
we'll
know
that
something
went
wrong
again.
This
is
another
great
time
to
ask
questions.
If
anybody
has
any.
A
Yeah
ask
away
people
we
only
have
about
10-ish
minutes
left.
So
if
you
have
any
questions
in
mind
to
send
them
to
the
chat
so
that
we
can
get
them
answered,
yeah.
B
And
everything
is
all
green,
that's
good!
You
do
see
a
warning
up
here,
because
since
cert
manager
is
messing
with
all
this,
for
us,
cert
manager
can
use
very,
very
short
certificate.
Expirations
it
just
it's
a
program,
not
a
human,
so
it's
going
to
be
rotating
every
24
hours,
and
this
is
a
good
thing
for
security.
B
To
see
a
warning
about
that,
so
when
all
is
said
and
done,
if
you've
done
this
correctly
and
if
cert
manager
is
functioning,
you
will
end
up
with
the
linkedin
identity,
trust
roots
secret
in
the
cert
manager.
Namespace,
that's
the
one
that
you
want
to
make
sure
other
people
can't
get
at
other
workloads
should
not
be
able
to
see
this.
B
If
you
don't
see
those
something
is
wrong
and
liquidity
check
should
tell
you
about
it,
but
that's
what
you'll
end
up
with
so
there
you
have
it.
That's
automated
cert
bootstrapping,
like
you
like.
We
already
saw
since
there's
a
program
managing
the
issuer
certs.
It
can
do
them
every
day
to
will
really
increase
security
there.
B
The
only
downside
of
doing
it
this
way
exactly
the
way
we
did
it
is
that
the
private
key
for
the
trust
anchor
actually
is
in
the
cluster
right
now
you
have
to
protect
that
a
better
way
of
doing
this
would
be
setting
it
up
so
that
it's
stored
off
cluster
and
all
that,
but
that's
very
much
out
of
the
scope
for
this
presentation.
B
So
with
that
in
mind,
do
we
have
other
questions.
A
Not
so
far,
but
usually
at
least
in
the
past,
when
we
start
saying
last
call
then
there's
gonna
be
a
bit
more,
so
we
can
wait
a
bit
for
those
but
yeah
eight
minutes
left,
and
then
we
have
to
finish
so
there's
only
a
time
for
your
questions,
and
here
we
come
here.
We
go
the
first
one
comes
in.
B
I
would
find
it
a
little
strange
to
run
istio
and
liberty
in
the
same
cluster
they're
kind
of
doing
the
same
job,
but
doing
it
in
very,
very
different
ways.
So
not
gonna
lie,
I
don't
actually
know
about
istio
insert
manager
interacting
but
yeah.
B
Sorry,
that's
not!
That
doesn't
feel
like
a
great
answer,
but
that's
what
I
got
a
bit
more
on
the
trust
anchor
the
issuer,
certs
and
other
certs.
Let
me
see
if
I
can't
get
that
slide
back
quickly.
A
Perfect
and
no
worries
if
there
was
no
info
on
the
first
question.
I
guess
people
can
also
reach
out
to
you
via
on
linkedin
or
twitter
or
some
other
places
if
they
really
really
need
some
and
their
answers
in
the
future
as
well.
But
we
see
tahir,
saying
no
problem
you're
right
so.
B
Well,
so
this
is
the
the
overview
of
the
relationship
between
the
trust
anchor
and
the
issue.
Research
and
all
that,
where
the
trust
anchor
is
the
root
of
everything,
the
trust
anchor
signs.
The
issuer
certificates,
which
sign
workload,
certificates
which
are
attached
to
workloads
and
the
trust
anchor.
B
We
go
okay,
sorry
about
that
yeah.
So
the
trust
anchor
certificate
is
the
root
of
all
trust
for
lingerie.
It
signs
the
issuer
certificates.
The
issuer
certificate
sign
workload,
certificates
workload,
certificates
are
attached
to
workloads
to
protect
communications
between
them,
the
trust
anchor.
It
doesn't
really
matter
who
signed
the
trust
anchor,
but
it
must
be
allowed
to
sign
other
certificates
and
in
fact
it
must
have
a
path
link
it
but
path
length
of
at
least
one,
because
it
needs
to
sign
the
issuer
certificates
which
sign
the
workload
certificates
and
in
x.
A
Perfect
and
then
there
was
a
question
from
mutairu
about:
is
there
a
possibility
of
getting
a
pre-recorded
form
of
this
video
tutorial?
This
precise
tutorial
that
we
have
recorded
today
will
be
available
as
on
demand,
like
a
recorded
version
in
the
cloud
native
live
playlist
in
cncf
youtube.
It
should
be
available
pretty
much
immediately
after
this
ends.
So
no
worries
this
precise
one.
You
can
rewatch
any
time
you
want
from
the
youtube
if
there's
any
other.
A
B
The
the
repo
for
the
workshop
is
probably
the
best
place
to
go
for
resources,
there's
not
video
in
there,
but
there's
a
lot
of
you
know
a
lot
of
pros.
That
might
be
a
lot
easier
to
read
than
following,
along
on
the
video.
A
Perfect
and
then
we
had
a
comment.
Thank
you
so
much
you
guys
are
the
best.
Thank
you
so
much
to
you,
yeah,
you
are
the
best
as
well
to
be
the
as
well
perfect
yeah,
and
then
we
have
a
link.
Would
you
have
the
link
for
their
repo
or
the
slide
with
the
repo
link?
I.
B
There
we
go
yeah,
so
everything
for
this
workshop
is
in
the
buoyant
io
service,
smash
academy,
repo
on
github,
specifically
the
l5d
certificate
management
directory,
there's
a
bunch
of
stuff
already
there.
I'm
probably
gonna
update
a
couple
of
things
you
know
later
today,
but
it's
okay
go
ahead
and
look,
and
I
should
have
had
a
link
to
the
slack
as
well.
B
A
B
Had
a
final
yeah,
one
final
comment:
cube
crash:
it's
happening
before
kubecon,
there's
some
cool
stuff
going
on
there
by
all
means,
go
over
and
take
a
look
at
that
we'd
love
to
see
you
there,
it's
virtual,
it's
free,
easy
to
make,
and
also
we've
mentioned
the
service
mesh
academy.
A
couple
of
times
we
do
a
bunch
of
stuff
like
this.
That's
focused
on
linker
d,
also
love
to
see
you.
There.
A
A
Yeah,
exactly
that's,
that's
the
important
part.
So
thank
you.
Everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
really
great
to
have
a
session
about
certificate
management
with
linkery
and
thank
you
everyone
for
the
interaction
and
thank
you,
everyone
for
the
questions
and
as
always,
we
bring
you
the
latest
cloud
native
code
every
wednesday
and
in
the
coming
weeks
we
have
more
great
sessions
coming
up.
So
thank
you
for
joining
us
today
and
we
will
see
you
in
the
coming
weeks.