►
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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
Foreign
Welcome
to
Cloud
native,
live
where
we
dive
into
the
code
behind
Cloud
native
I'm,
Annie,
talasto
and
I'm.
A
cncf,
Ambassador
and
I
will
be
your
host
Tonight.
So
every
week,
we're
being
a
newsletter
presenters
to
Showcase
how
to
work
with
Cloud
native
Technologies.
They
will
build
things,
they
will
break
things
and
they
will
answer
all
of
your
questions,
so
you
can
join
us
every
Wednesday
to
watch
live
so
this
week
we
have
Lynn
and
Richard
here
with
us
to
talk
about
real
world
real
world
trust
management.
A
Linkage,
insert
manager
and
as
always,
this
is
an
official
live
stream
of
the
cncf
and
as
such
it
is
subject
to
the
cntf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
So
basically,
please
be
respectful
of
all
of
your
fellow
participants
as
well
as
presenters,
but
with
that
done
I'll
hand
it
over
to
Flynn
and
Richard
to
kick
off
today's
presentation.
B
Thanks
for
the
introduction
Annie
glad
to
be
here,
we
are
going
to
talk
about
real
world
trust
management
with
liberty
and
Trust
manager,
sorry,
linkerty
and
cert
manager.
We
will
also
be
talking
about
a
thing
called
trust
manager
in
there
as
well.
That's
kind
of
related
to
cert
manager.
Also,
you
can
reach
both
of
us.
Well,
you
can
reach
me
on
the
linkery
slack
and
the
cncf
slack
as
Flynn.
You
can
reach
Richard
as
Richard
wall
on
the
cncf
slack.
B
So
if
you
have
questions
after
this,
that's
the
best
way
to
reach
us
and
what
we're
gonna
do
today
is
we
will
talk
a
bit
about
Linker
the
insert
manager
a
bit
about
certificates
themselves
and
how
identity
works
in
Liberty?
How
assert
manager
helps
with
that,
and
then
we
will
dive
into
a
demo.
The
agenda
sounds
like
a
bunch
of
things
for
slides.
It
will
go
pretty
quickly,
we're
mostly
going
to
be
dealing
with
the
demo
here,
but
there's
some
background.
B
That's
kind
of
important
as
we
talk
about,
especially
when
we're
talking
about
trust
and
certificates
and
all
this
stuff,
so
Linker
d,
the
very,
very
quick
demo.
It's
the
only
cncf
graduated
service
mesh.
It's
purpose
in
life,
is
to
bring
security,
reliability
and
observability
to
every
cloud
native
application
and
every
cloud
native
developer,
and
it
is
mostly
brought
to
you
by
buoyant
where
I
work,
full
disclosure
cert
manager
is
a
cncf
incubating
project
whose
purpose
in
life
is
to
automate
provisioning
and
managing
certificates.
B
B
B
So
why
would
you
use
both
of
these
tools?
If
you
look
back
at
what
I
just
said
about
link
reduce
purpose
in
life,
security
features
prominently,
security
and
likerty
relies
on
mtls
mtls
in
turn
relies
on
certificates.
You
can
manage
all
these
certificates
by
hand.
You
really
do
not
want
to
the
reason
you
don't
want
to
is
that
if
you
get
it
wrong,
it
will
cause
downtime,
and
then
everybody
will
yell
at
you.
So
you
really
don't
want
to
do
this
by
hand.
Instead,
you
want
to
use
a
tool
like
cert
manager
really
quickly.
B
Let's
talk
a
bit
about
certificates
themselves,
they
tends
to
be
a
thing
that
is
relatively
poorly
understood
everywhere.
Actually,
not
just
in
the
cloud
native
world
certificates
rely
on
public
key
cryptography,
they
form
the
basis
of
trust
and
linkerty.
Public
key
crypto
is
pretty
cool
because
it
allows
you
to
safely
communicate
and
do
authentication,
irrespective
of
whether
the
entity
is
communicating
and
authenticating
know
much
about
each
other.
I
mtls
relies
on
all
this
stuff.
B
If
we
could
get
that
YouTube
link
posted
into
the
chat
that
would
be
lovely
if
anybody
wants
to
go
back
and
get
the
kind
of
the
deeper
dive,
I'm
deliberately
doing
the
less
Deep
dive
on
it
right
now
to
make
all
of
this
stuff
work,
though,
both
in
the
sense
of
whenever
you're
dealing
with
public
key
cryptography,
but
also
when
you're
talking
specifically
about
certificates,
there's
a
private
key
and
a
public
key,
the
private
key
must
be
kept
private.
They
form
the
basis
of
identity
and
Liberty.
B
This
creates
a
problem
because
keeping
track
of
all
these
Keys
is
difficult
and
to
deal
with
that
problem.
This
certificate
thing
was
invented
more
correctly,
we're
talking
about
x.509
certificates.
They
are
data
structure
that
take
a
subject
which
is
really
the
name
of
the
entity
being
identified
and
they
bind
it
up
with
a
and
public
and
private
key
pair.
B
Only
the
public,
oh
there's,
the
YouTube
leak
great.
If
anybody
wants
that,
only
public
information
is
contained
in
the
certificate.
They
are
always
completely
safe
to
share
around
there's
absolutely
nothing
in
them.
That's
private!
This
is
actually
a
critical
point,
because
you're
supposed
to
share
these
things
so
that
they
can
be
used
for
identity
verification,
they
are
signed.
Here's
the
signature
block
for
this
one.
B
B
Rotation
is
the
name
given
to
the
process
of
generating
a
new
key
pair
and
swapping
it
in
for
a
certificate
so
that
you
don't
have
to
rely
on
a
key
for
a
very
long
time,
all
right
we're
going
to
dive
into
how
certificates
get
used
in
linkerty,
so
that
we
can
talk
about
how
we
can
get
cert
manager
to
help
out
with
that
in
linkerty.
I.
Keep
hitting
my
mic.
Excuse
me
that
probably
is
very
loud
in
Linker
D,
we
start
with
workloads
in
a
cluster.
B
B
The
workload
certificates
are,
in
turn
signed
by
a
thing
called
the
identity
issuer
certificate
in
linkerty,
and
then
one
layer
up
from
that,
we
have
linkages
trust
anchor
certificate
which
signs
the
Azure
certificate.
The
reason
that
we
have
both
of
these
both
of
these
both
the
issuer
certificate
and
the
trust
I
care
certificate.
B
There
are
actually
a
couple
of
major
reasons.
The
first
one
is
that
it
makes
it
very
much
easier
to
just
swap
out
issue
research
fairly
frequently
without
having
to
mess
with
everything.
It
also
limits
your
exposure
correspondingly.
If
one
of
these
certificates
gets
compromised
having
the
two
layers,
there
makes
it
a
bit
operationally
simpler
to
deal
with
that.
The
other
thing
going
on
here
is
that
it
tends
to
make
it
easier
to
insulate
these
identities
from
the
network
topology.
B
So,
for
example,
the
reason
that
you
would
have
two
issue
with
certificates
is,
if
they're
in
two
separate
clusters
entirely.
This
works
fine
with
Linker
D.
This
is
the
basis
of
linked
multi-cluster
world.
The
requirement
for
multi-cluster
is
basically
the
trust.
Anchor
has
to
be
the
same
across
your
entire
network,
topology
and
then
everything
else
will
just
work
now.
B
We
will
also
get
the
characteristic
that
all
of
the
certificates
shown
in
Gray
are
things
that
you
have
to
manage
by
hand.
We
talked
earlier
about
the
fact
that
you
don't
really
want
to
manage
certificates
by
hand.
Another
thing
I'll
throw
out
is
that
using
a
self-signed
certificate
for
the
trust,
anchor
is
really
not
ideal
for
likerty
in
production,
so
better
not
to
do
that.
B
What
we're
going
to
do
today
is
focus
on
a
case
where
we're
using
cert
manager
instead,
where
we've
got
the
workload
search
and
the
issue,
research
and
the
trust
anchor,
but
we
use
cert
manager
to
provide
an
extra
layer
for
the
certifying
Authority
Route.
The
ca
route,
then
signs
the
trust,
anchor
and
maybe,
most
importantly,
all
of
the
certs
in
Gray
are
now
going
to
be
managed
by
cert
manager
instead
of
managing
them
by
hand.
B
B
The
point
the
the
biggest
thing
to
remember
here
is
that
you're
probably
not
going
to
know
if
a
certificate
is
compromised,
so
once
it's
compromised,
it
will
stay
compromised
and
you
probably
won't
know
about
it
until
the
next
time
you
rotate
the
certificate.
So
if
the
time
to
the
next
rotation
is
very
very
long,
that
gives
your
evildoer
longer
to
do
evil
things.
If
it's
very
short,
it
mitigates
that
risk
there.
It
mitigates
the
damage
they
can
do.
B
The
countervailing
pressure
here
is
that
if
you're,
you
know
spending
all
of
your
time
rotating
certificates,
you
are
not
spending
your
time,
actually
accomplishing
things
that
you
want
to
do,
and
so
there's
a
balance
to
be
struck
there.
I
cannot
tell
you
what
that
balance
is.
I
can
tell
you
that
you
need
to
evaluate
your
risk
tolerance.
You
need
to
evaluate
how
much
operational
complexity
you're
willing
to
tolerate
and
then
come
up
with
something
that
works
out.
B
Okay
for
you,
I
will
point
out
that
by
default,
for
example,
when
you
use
the
Linker
dcli
to
install
Linker
d,
that
will
create
a
self-signed
trust
anchor,
that's
good
for
a
decade.
That's
too
long,
in
my
opinion,
I
would
not
recommend
doing
that.
The
other
thing
that's
very
important
here
and
another
reason
why
I
would
not
recommend
expert
times
out
to
a
decade
is
that
you
really
have
to
actually
do
the
rotation
so
that
you
know
how
to
do
it
as
opposed
to
just
going.
Oh,
we
wrote
it
down.
B
Everything
will
be
great
because
what
will
happen
if
you
don't
actually
practice
the
rotation
is
that
something
will
happen.
If
you
will
be
compromised,
it
will
certainly
be
an
emergency
and
then
you'll
end
up
scrambling
around
in
practice,
trying
to
figure
out
how
to
do
this,
while
you're
under
time
pressure
or
monetary
pressure
or
people
yelling
at
you
or
all
of
the
above
I
would
love
to
tell
you
that
I
did
not
learn
this.
B
You
know
the
hard
way,
but
in
fact,
I
have
been
in
exactly
the
situation.
Don't
make
my
mistakes
from
younger
me?
It's
really
much
much
better
to
just
automate
it
all,
whether
you
automate
it
or
not,
actually
practice
the
rotation
thing
and
make
sure
that
the
people
who
are
still
at
the
company
know
how
to
do
this.
I
think
we're
about
to
dive
in
on
the
demo
stuff
Richard
was
there
anything
that
you
wanted
to
add
to
all
this.
B
B
B
B
That's
just
part
of
that
is
because
kubernetes
Secrets
themselves
are
far
from
ideal.
Let's
just
say:
if
you
have
our
back
access,
you
can
go
and
see
the
secret
in
all
its
Glory.
You
can
read
it
back.
You
can
do
whatever
you
want
to
it
to
it
and
yeah.
So
secrets
are
a
little
bit
less
secure
than
their
reputation
often
implies,
but
the
other
one
is
just
a
general
security
principle,
the
principle
of
least
access.
B
If
you
are
trying
to
do
things
that
are
where
security
is
important
and
security
is
always
important,
you
should
always
arrange
it
such
that
a
given
entity
does
not
have
access
to
things.
It
doesn't
need
to
that's
much
less
about
reducing
Temptation
and
much
more
about
reducing
the
blast
radius
from
the
inevitable
mistakes
that
will
be
made.
B
C
Well
from
the
Sun
from
the
passive
of
the
cert
manager
maintainers,
we
know
that
when
you
install
cert
manager
to
make
it
easily
installable
and
to
work
out
of
the
box,
we
the
our
back
that
we
ship
with
cert
manager
allows
it
to
read
and
write
every
secret
in
the
kubernetes
cluster.
Yes,
it
needn't,
be
it
needn't.
Do
that,
but
there's
just
there's,
there's
no
really
good
mechanism
to
allow
it.
Only
the
access
to
the
secrets
that
it
manages.
At
least
we
haven't,
figured
that
out
yet.
B
B
C
Is
an
operator
that
you
install
in
kubernetes
and
it
has
a
Series-
has
a
bunch
of
crds
custom
resource
definitions
which
allow
you
to
configure
the
desired
state
of
a
TLS
certificate
which
will
be
signed
by
a
by
an
external
issuer
or
by
cert
manager
itself,
depending
on
what
your
requirements
are,
and
the
issuers
that
cert
manager
can
interact
with
are
quite
extensive.
There's
there
are
five
built-in
issuers
and
there's
an
ex
there's
a
plug-in
mechanism
which
allows
people
to
write
external
issues
for
projects
such
as
Google's
Google,
Ca
service.
B
C
That's
the
bit
I
should
have
said
yeah
people
what
people
have
done
until
the
invention
of
trust
manager.
Cert
manager
will
put
the
ca
certificate
in
the
same
secret
as
the
private
key
in
the
signed
certificate,
and
people
have
tended
to
Mount
that
secret
in
for
the
for
the
benefit
of
the
clients
that
need
to
verify
the
servers
that
are
that
actually
need
to
consume
the
private
key
and
signed
certificate.
C
B
B
Okay,
we
will
now
go
and
do
a
demo
and
hope
that
the
demo
Gods
smile
upon
us
there's
a
bit
of
a
white
lie
in
this
slide,
which
is
that
Richard
and
I
were
going
through
and
editing
a
bunch
of
things
in
the
demo.
So
it's
not
actually
available
at
that
pki
and
production
directory
yet,
but
it
will
be
shortly
and
we
will
be
using
a
few
tools
here,
we'll
be
using
step.
B
B
A
B
B
B
C
B
Quick,
this
demo
should
work
just
fine,
if
you
do
it
in
k3d
or
if
you
do
it
in
kind.
I
have
in
fact
done
it
in
k3d,
but
but
today
we're
going
to
use
this
Evo
cluster
I
tried
it
in
kind.
It
did
work
for
me
in
kind,
excellent,
I'm
glad
to
hear
it
all
right,
so
we're
going
to
start
by
setting
up
Helm
so
that
we
can
use
Helm
to
install
linkerty
and
cert
manager
and
Trust
manager
and
I'm
pretty
sure
that
these
repos
all
exist
already
for
me.
B
B
B
I
will
update
the
demo
and
and
I
assume
everything
will
still
work
after
cert
manager
has
been
installed.
We
will
switch
over
to
install
trust
manager
or
assert
manager,
trust
I,
guess
its
official
chart
name
is
same
thing,
we're
going
to
install
and
then
we're
going
to
wait
for
it
to
come
up
and
be
running.
B
B
Excellent,
all
right
so
now
we
have
cert
manager
installed
and
we
have
trust
manager
installed.
Next
up
we're
going
to
set
up
cert
manager
in
a
slightly
less
than
Production
Way
we're
first
going
to
use.
So
if
you
remember
the
slide
from
earlier,
actually
let
me
get
to
that
slide
from
earlier
and
then
I'll
bring
it
back
up.
B
B
Okay,
you
assert
manager
to
create
a
self-signed
groups
again.
We
will
then
use
the
root
CA
to
create
a
trust
anchor
certificate
signed
by
the
root
CA
and
backing
up
to
our
previous
conversation
about
private
keys
and
such
cert
manager
will
be
creating
the
trust
anchor
certificate
in
the
search
manager.
Namespace
and
Legacy
will
have
no
access
to
it
at
all,
not
to
the
private
key,
not
to
the
public
key,
nothing
at
all.
B
B
B
Okay.
So
your
color
point
where
I
said
that
we're
going
to
use
cert
manager
to
create
things
in
the
search
manager
namespace,
but
we
have
to
copy
them
into
the
likerty
namespace.
That
implies
that
we
need
for
the
Linker
D
namespace
to
exist,
so
we'll
go
ahead
and
create
it
first.
Next
up
we're
going
to
use
you're
going
to
set
up
that
root
CA,
and
we
will
use
a
cert
manager
custom
resource
to
do
this.
B
C
C
B
C
B
B
B
It
is
easy
with
cert
manager
to
swap
the
CAA
Cas
out,
so
you
actually
can
do
things
like
bootstrap
with
this
software
self-signed
issue,
where,
like
we're
doing
here
and
then
go
through
and
tweak
things
without
having
to
completely
tear
the
cluster
down
all
right.
So
let's
go
ahead
and
apply
that,
and
now
that
we
have
that
self-signed
root
CA,
we
will
tell
cert
manager
how
to
create
the
trust
anchor
certificate.
B
B
In
the
x.509
Community,
you
will
very
commonly
hear
people
talking
about
issuing
certificates
outside
it.
You
will
often
hear
people
talk
about
signing
certificates.
They
are
the
same
thing.
Cert
manager
talks
about
issuers,
so
the
issuer
for
this
cert
will
be
our
cluster
issuer
that
we
just
created
the
self-signed
one.
B
We
will
specify
that
it
will
use
a
256
bit
elliptic
curve,
digital
signature,
algorithm,
private
key
and
it
will
be
stored
in
a
secret
named
liquidy
identity,
trust
Roots,
which
again
will
live
in
the
cert
manager.
Namespace,
we
didn't
say
anything
about
durations
or
renewal
times
or
anything
like
that.
I
should
actually
double
check
this
with
Richard.
This
comment's
been
around
for
a
really
long
time.
Is
this
actually
the
correct
default
value
here?
Is
it
90
days
and
renewed
at
30
days,
or
is
that
no
longer
true.
B
Okay,
after
creating
that
trust
anchor
certificate
and
we're
going
to
define
a
second
cluster
issuer
that,
instead
of
being
self-signed,
we'll
use
that
shiny
new
certificate
that
we
just
created
to
issue
certificates
and
that
will
be
called
the
Linker
D
trust
anchor
cluster
issuer.
But
again
that
will
be
insert
manager,
namespace,
okay,
so
we're
going
to
apply
both
of
those.
B
Now,
issuing
certificates
is
fast
when
you're
dealing
with
cert
manager,
which
is
kind
of
nice.
So
in
fact
the
trust
anchor
should
already
be
there
and
we
should
be
able
to
look
at
it
using
Coupe
control
describe
secrets.
We
can
see
that
well,
it's
there.
It
has
the
right
name:
it's
in
the
namespace.
We
expect
it
has
a
ton
of
annotations,
which
is
all
right.
It
also
has
various
Keys
TLS
dot
key
is
the
private
key
in
the
secret
tls.crt
is
the
public
half
of
that
key
and
ca.cert?
Is
the
issuers
public
key?
B
B
This
is
one
of
the
Annoying
bits
about
one
of
the
Annoying
bits
about
secrets
in
kubernetes.
Is
that
the
actual
value
of
a
an
x509
certificate?
It's
usually
rendered
as
a
pem
format,
which
is
itself
base64
encoded?
Then
kubernetes,
base64
encodes,
it
again.
So
if
we
want
to,
though
we
can
use
this
horrible
bit
of
Coupe
control
stuff
to
pull
out
the
public
key
and
then
decode
it
and
then
pass
it
to
step
certificate
inspect.
B
So
we
can
see
what
that
certificate
actually
looks
like,
and
it
actually
looks
like
this,
where
it's
got
a
subject
of
root.liquity.cluster.local
and
we've
got
the
public
key
and
we've
got
the
signature
algorithm.
Everything
is
great
all
right
now,
given
that
we
have
that
trust
anchor
certificate
and
we
have
a
corresponding
CA
going
with
it.
Then
we
will
tell
cert
manager
how
we
want
it
to
use
that
to
create
the
identity
issuer
certificate
as
well.
B
B
We're
also
going
to
explicitly
say
that
this
certificate
will
only
be
good
for
48
hours
and
it
must
be
renewed,
no
more
than
25
hours
after
issuing
this
is
a
relatively
common
thing.
It
is
possible
for
the
renewal
to
fail
in
the
you
know
in
the
real
world
in
practice.
So
if
you
have
something
that
expires
at
48,
Hours,
don't
try
to
don't
only
try
to
renew
it
at
47
hours,
renew
like
halfway
through
your
actual
validity
period.
B
B
C
B
B
Not
time
into
your
life
span,
okay,
excellent
right.
This
one
will
be
issued
by
the
Lincoln
trust
anchor
issuer,
not
the
the
route.
Ca
still
doing
a
256
bit
ecdsa
key,
but
this
one
will
be
stored
in
a
secret
named
Linker.
The
identity
issuer
again
in
the
Linker
D
namespace,
not
the
server
manager
namespace,
so
we'll
apply
this
one
and
once
again
creating
certificates
is
fast.
B
We
can
see
that
that
certificate
is
there
in
a
secret,
and
we
can
repeat
pretty
much
exactly
the
same
thing
that
we
did
earlier
with
grabbing
data.tls.crt.
It's
probably
worth
pointing
out.
The
backslash
here
is
important
because
the
dot
is
actually
part
of
the
key
name.
Here:
it's
not
the
separator,
not
a
hierarchy,
separator.
Thank
you!
Kubernetes
base64-d,
to
decode
it
step
in
certificate,
inspect
to
look
at
it,
and
we
can
see
here
that
the
subject
is
identity.linkerty.cluster.local.
It
was
issued
by
root.linkerty.cluster.local.
B
B
And
that
config
map
is
actually
always
the
thing
that
Linker
d
looks
at
to
figure
out
how
to
verify
workload.
You
know
how
to
verify
their
certificates.
It
always
looks
into
a
config
map,
not
a
secret,
for
the
keys
for
the
trust
anchor
because,
as
we
were
pointing
out
earlier,
there's
nothing
secret
about
the
public
key.
We
don't
need
a
kubernetes
secret.
A
config
map
is
just
fine,
so
you
were
going
to
say.
C
B
C
B
There
actually
is,
if
I
remember
correctly,
there
is
a
slight
additional
expense
on
the
API
server
for
Secrets
instead
of
config
maps,
and
so
it
it
where
they
don't
need
Secrets,
they
don't
use
them
so,
creating
again
trust
manager
is
fast
in
copying
things
into
the
config
map.
So
we
can
look
and
see
that
there
you
go,
we
could
go
and
pull
out
the
key
and
run
that
through
step
certificate
inspect,
but
I'm
not
going
to
bother,
because
we've
done
that
already
so
many
times.
B
Finally,
having
done
that,
we
get
to
install
Linker
d,
we
are
not
going
to
use
the
Linker
dcli
for
this.
We
will
use
helm
first
off,
because
Helm
is
arguably
a
little
bit
better
for
production
installation.
It
makes
it
a
bit
easier
to
do
upgrades
and
things
like
that,
but
also
because
you're
going
to
see
how
to
use
Helm
to
tell
linkerty
to
use
cert
manager
CA
rather
than
spinning
up
stuff
on
its
own
first
things.
First,
we
must
install
the
Linker
dcrds.
Then
we
will
go
and
install
the
link,
ready,
control,
plane
itself.
B
C
Can
I
can
I
say
yeah
a
note.
I
agree
with
that.
I
agree
with
the
way
you're
installing
the
crds
first
and
that's
actually
what
we
advise
people
to
how
people?
That's
that's
how
we
advise
people
to
install
cert
manager
2.
when
we
installed
cert
manager.
Earlier
we
we
use
the
install
crds
flag
in
the
helm
chart,
but
that's
not
what
you
should
do
in
production,
because.
C
B
Oh
look,
it
actually
finished
and
an
interesting
thing
here
is:
we
can
see
that
the
trust
anchor
is
valid.
The
trust
anchor
is
valid
for
at
least
60
days.
In
fact
it's
developed
for
90
days,
but
we
can
actually
see
that
our
issue
research
is
complaining
in
Liberty
check
because
it's
going
to
expire
in
only
two
days.
That's
okay!
That's
what
we
told
it
to
do.
B
Just
a
thing
to
be
aware
of
all
right
now,
one
last
thing
we're
going
to
do
before
handing
it
over
to
talk
having
to
get
over
to
let
Richard
talk
about
more
production.
Real
setup
is
we're
going
to
install
our
Emoji
photo
demo
application,
and
the
reason
for
that
is
that
I
want
to
show
y'all
how
to
look
at
the
workload
certs
as
well
and
make
sure
that
they
are
signed
by
the
correct
things.
B
There
we
go
so
Emoji
photo
is
now
running
and
we
can
use
the
Linker
dcli,
the
Linker,
the
identity
command.
To
look
to
show
us
identity.
You
know
workload
certificates
within
the
Emoji
photo
namespace
that
match
the
label
app
equals
Emoji
service.
That
will
be
exactly
one
workload
in
the
Emoji
photo
namespace
as
it
happens,
and
if
we
do
that,
we
can
see
that
it
has
a
subject
of
emoji.moji
photo.surface
account.identity.linkerty.cluster.local.
B
B
We
can
also
see
if
we
look
down
into
these
extensions.
You
will
see
that
this
is
not
a
CA
certificate.
It
cannot
be
used
to
sign
anything
else
which
is
good
Okay,
so
that
is
all
about
going
through
and
setting
up
cert
manager,
with
a
self-signed
issuer
about
having
cert
manager
do
all
of
the
certificate
management
for
us
and
now
Richard
I
think
you
were
going
to
share
your
screen
here
right
yes
and
talk
just
a
bit
about
doing
this,
a
bit
more
realistically
with
Vault
instead
of
a
self-signed
issuer,
I'll.
B
C
C
A
C
C
Various
others
yeah
and
in
the
interests
of
making
verify
TPP,
is
an
Enterprise.
It's
a
piece
of
enterprise
software
which
I'm
familiar
with,
but
it's
not
it's
not
free
for
for
anyone
to
use
and
it's
quite
difficult
to
set
up.
So
we
chose
instead,
the
hashicorp
vault,
which
is
available
for
people
to
install
themselves
and
it's
quite
easy
to
set
up
inside
kubernetes
and
that's
what
I've
done.
C
C
Then
what
you
can
do
is
you
can
set
up
a
cert
manager
to
be
able
to
connect
to
that
Vault
server.
In
this
case,
we've
done
it
in
a
very
simple
way
by
providing
its
API
token
in
a
secret.
But
you
wouldn't
do
this
in
production.
You
would
use
like
a
workload
Federation
system
which
it
supports
as
well,
where
you
can
use
an
ephemeral.
Kubernetes
service
account
token
to
authenticate
the
vault.
C
C
C
A
C
This
yeah,
this
API
endpoint,
is
not
the
standard
API
endpoint,
it's
a
it's
a
an
endpoint
dedic,
a
dedicated
endpoint
for
signing
intermediate
certificates.
So
that's
that's
important
and,
as
Flynn
said,
we'll
we'll
publish
this
to
the
repository
later
once
we've
tied
it
tied
it
up.
Really
we
were
doing
this.
I
was
doing
this
right
at
the
last
minute,
so
apologies
for
not
being
more
prepared.
C
C
The
certificate,
though,
is
basically
the
same.
It's
exactly
as
Flynn
showed
earlier
with
a
common
name,
which
is
significant.
It
must
be
this
common
name
for
Linker
D
to
to
use
it.
It
must
be
marked
as
a
CA
certificate,
but
this
time
in
the
issuer
ref
we
let
we
refer
to
this
vault
issuer,
which
I
showed
you
and
when
we
deploy
this
cert
manager,
will
let's
look
at
the
certificates.
Cube
CTL
get
cert
minus
n
link
e.
B
We
should
probably
point
out
here
that
this
is
a
different
cluster
than
the
one
that
I
was
using,
where
just
in
the
interest
of
time
Richard
went
through
and
set
all
this
stuff
up
and
then
is
walking
through.
So
this
is
this
is
a
kind
cluster
right,
yeah
yeah,
again
shouldn't
really
matter
what
kind
of
cluster
it
is
pun
not
intended.
C
C
B
B
B
C
A
C
B
C
B
And
again,
we
should
emphasize
here
that
the
Vault
setup
that
Richard
reads
using
is
not
really
the
production
Vault
setup,
but
the
way
in
which
cert
manager
is
pulling
all
this
stuff
out
of
Vault.
The
way
cert
manager
is
interacting
with
it.
That
part
will
work
fine
with
a
properly
production-ready
Vault
instance
yeah
excellent.
A
B
B
There's
a
truly
atrocious
URL
that
I
could
post
here,
but
instead
I'll
just
say:
go
to
lincoln.io
click
on
the
community
menu
and
you'll
see
the
Liberty
day.
2023
EU
thing
to
click
on
also
coming
up
is
Coupe
crash
as
well
brought
to
you
by
a
number
of
people,
including
boyet
and
sibo,
and
Cockroach
and
Fairwinds
and
jetstack.
C
A
The
fact
that
we're
sharing
your
contact
details
here
so
if
anyone
has
any
questions,
please
go
ahead,
jump
over
to
to
flynns
and
Richard's
info
and
ask
the
questions
there
and
I
think
this
works,
and
this
bit
of
stalling
for
me
and
no
questions
came
in
that
time
either.
So
we're
perfect,
so
yeah
jump
to
those
contact
details
with
your
questions
and
we'll
start
wrapping
it
up
really
good
content,
though
I
really
loved
it.
Yeah.
A
The
latest
episode
of
cloud
native
live.
It
was
great
to
have
a
session
about
real
world
trust
management
with
Linker
the
insert
manager.
We
also
really
allowed
to
view
audience
comments
that
we
have
and
always
look
forward
to
those,
but
as
always,
we
bring
you
the
latest
Cloud
native
code,
every
Wednesday
and
in
the
coming
weeks,
there's
even
more
sessions
coming
up
and
they're
going
to
be
great
so
tune
in.
So
thanks
for
joining
us
today
and
see
you
all
next
week.
Thank.