►
From YouTube: Securing Edge Workloads With Cert-Manager And SPIFFE - Sitaram IYER & Riaz Mohamed, Jetstack Ltd
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 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.
Securing Edge Workloads With Cert-Manager And SPIFFE - Sitaram IYER & Riaz Mohamed, Jetstack Ltd
Speakers: Sitaram Iyer, Riaz Mohamed
Workloads are moving from data centers to the edge more than ever. As workloads migrate to the cloud many enterprise IT firms are seeing compute resources moving closer to where the data is created. Edge computing models have become far more attractive to many industries like telecom, farming, public safety, retail, medical, etc., because of the ability to minimize network latency and to put essential functions closer to the technology consumer. The rate at which Kubernetes has been adopted to run these workloads have been exponentially increasing as is seen with 5G network deployments. How do we secure these workloads? Be it ingress, pod to pod (mTLS) security, and trust domains. How do we manage certificates and renewals at scale? How do we enable security policies and postures on edge locations? The talk will go through how to manage security at the edge using cert-manager and utilizing SPIFFE as a way to manage and distribute trust. We will run cert-manager on a raspberry pi and look at provisioning and renewing certificates for both ingress and mTLS use cases.
B
A
And
we,
our
job,
obviously
at
jet
stack,
is
to
talk
to
many
of
our
customers
and,
and
one
of
the
things
that
we
have
heard
many
offer
very
often
is
you
know
the
challenges
around
securing
workloads,
especially
as
they
are
deployed
across
multiple
different
clusters.
Multiple
different
you
know,
domains
and
and,
as
we
sort
of
you
know,
started
to
think
about
the
motivation
for
this
session.
A
We
essentially
wanted
to
look
at
it
purely
from
a
perspective
of
what
does
it
take
to
provide
a
standard
way
of
generating
identities
for
workloads
across
clusters
and
essentially
build
trust.
That's
a
simple
motivation
that
we
started
to
look
at
this
from
securing
workloads
having
an
ability
to
generate
an
identity
and
distributing
trust
across
multiple
different
trust
domains.
A
That
was
the
purpose
with
which
we
started
thinking
about
the
challenge
that
needs
to
be
addressed,
and
this
actually
started
off
purely
from
you
know,
many
of
the
conversations
that
we
have
had
with
some
of
the
customers,
and
specifically
a
customer
that
is
in
the
financial
space
and
and
while
this
picture
that
you
see
here,
may
look
very
simple.
The
challenge
that
that
the
specific
financial
institution
had
is
is
is
massive,
and
you
know
we
will
demonstrate
you
know
with
with
some
of
the
edge
devices
that
we
have
here.
A
You
know
how
we
have
addressed,
that,
how
we
have
solved
that
and
what
does
it
mean
to
to
to
address
and
secure
workloads?
So
what
you're,
seeing
there
on
the
picture
is
a
bunch
of
terminals,
obviously,
and
then
a
set
of
services
that
are
core
there.
The
simplest
way
to
sort
of
you
know
think
about
this.
Is
the
bank
here
provides
a
set
of
services
that
are
consumed
by
different
merchants
and
and
as
part
of
that,
the
merchant
terminal
that's
out
there?
A
Science
generates
some
kind
of
a
private
key
pair
sends
it
across
with
chart.
You
know,
obviously
the
bank
validates
it
and
sends
a
token
back
so
I'm
describing
this
in
a
very,
very
simple
form
and
over
a
period
of
time,
this
token
is
used
to
sort
of
you
know,
manage
payments,
refunds
and
things
like
that,
and
this
is
the
standard
operating
model
in
which
various
different
Merchants
work-
payment
terminals,
core
Bank
Services.
A
The
challenge
that
that
really
started
to
sort
of
you
know
surface
for
this
bank
was
when
a
merchant
terminal
was,
or
rather
a
merchant
was
off-boarded.
Terminals
were
lost,
terminals
were
sort
of
you
know,
repurposed
for
other
purposes,
and
that
sort
of
you
know
made
a
challenge
for
the
bank,
one
to
figure
out
who
is
using
the
terminal,
and
it
also
started
to
coming
to
the
notion
of
a
fraud
where
a
fake
Merchant
or
a
fake.
A
The
way
we
were
thinking
about
is
there
should
be
some
sort
of
a
trust
model
or
a
trust
that
can
be
established
in
a
way
where
services
on
the
back
end
know
exactly
what
the
terminals
are
and
how
they
work
and
the
same
way.
How
do
you
sort
of
you
know
manage,
or
rather
figure
out
a
way
to
sort
of
you
know
revoke
that
trust
when
a
merchant
is
on
board
off-border.
So
these
are
essentially
some
of
the
what-if
challenges
that
we
started
to
look
at.
A
So,
basically,
from
a
perspective
of
specific,
you
know
what
is
secure
identity
for
every
workload,
irrespective
of
where
they
are
running
on
a
very
simple
way
of
describing
it.
It
basically
allows
you
to
authenticate
mutually
in
an
easy
and
reliable
way.
Very
simple
definition:
obviously
we
want
to
get
a
little
bit
deeper
on
this
to
show
how
it
works
and
what
it
means.
A
But,
from
the
perspective
of
a
definition,
you
should
see
that
you
know
especially
essentially
allows
you
to
one
attach
some
kind
of
an
identity
to
a
workload
and
based
on
that
securely
and
mutually
and
reliably
allow
access
to
other
workloads,
as
you
sort
of
you
know,
talk
to
each
other,
so
the
last
last
bullet
there
obviously
is
something
that's
important,
specifically
just
graduated
within
the
clcf
and
which
also
means
that
if
you
go
to
the
cncf
store
there
you'll
find
a
lot
of
jackets
t-shirts.
Socks
feel
free
to
buy
them.
A
You
know
they're
nice
and
looks
good
the
other
project
that
I
want
to
talk
about
and
before
that
we
want
to
just
tin
a
little
bit
of
the
basics
of
spiffy.
You
know
we
hear
spiffy
a
lot
I'm,
pretty
sure.
A
lot
of
you
are
curious,
or
many
of
you
may
know
what
spiffy
does,
but
there
are
several
characteristics
of
spiffy
that
we
need
to
understand
before
we
sort
of
you
know
say
what
does
that
secure
identity?
A
Look
like
at
the
heart
of
you
know
anything
that
you
do
with
spiffy
is
a
workload
I
mean
we
keep
saying.
You
know
there
is
a
workload
that
needs
an
identity,
but
what
exactly
is
a
workload?
Workload
is
basically
any
software.
It
could
be
your
application,
it
could
be
a
database,
it
could
be
a
set
of
services
that
you
run.
It
could
be
something
that
you
run
in
a
cluster
within
a
node.
It's
a
part.
You
know
virtual
machine
whatever.
A
That
might
be
any
software
that
you
sort
of
you
know,
look
at
it
from
a
perspective
of
functionally
doing.
Something
is
a
workload
simply
put.
The
second
piece
which
is
important
to
understand
from
a
specific
perspective,
is
spiffy
ID,
and
this
is
something
that
you'll,
probably
sort
of
you
know
heard
quite
a
few
times.
Oh,
if
you're
using
spiffy,
you
need
to
generate
a
spiffy
ID.
A
What
does
ppid
even
mean
simply
put
it's
essentially
just
an
URI,
a
URI
that
identifies
a
workload
and,
most
often,
and
from
the
specification
perspective,
this
URI
is
represented
as
spiffy
colon,
slash
trust
domain,
slash
whatever
workload
that
you
want
to
identify
some
kind
of
an
identifier.
There
is
no
real
way
of
saying
you
know
this
has
to
be
in
a
certain
way.
The
example
that
you
see
there
represents
some
kind
of
a
trust
domain,
a
workload
that
is
in
a
certain
namespace
tied
to
a
certain
service
account
that
owns
that
deployment.
A
A
It's
one
thing
to
say
that
you
know
I
have
identified
or
I
have
an
ID
for
spiffy,
which
is
represented
by
some
kind
of
an
URI.
What
you
need
to
do
next
is
to
be
able
to
make
sure
that
you
know
this.
Identifier
can
be
attached
with
some
kind
of
a
cryptographically
verifiable
document
which
is
essentially
an
x59
certificate,
and
that's
essentially,
what's
PPS
weight
is
something
that
cryptographically
helps.
A
You
identify
something
that
you
have
signed
because
you
know
end
of
the
day
when
you
say
I
have
a
workload
that
workload
needs
to
be
tied
back
to
something
that
can
be
cryptographically
verifiable.
That's
previous
way,
then
there
is
specific
workload,
essentially
something
that
allows
you
for
the
private
key
to
be
signed,
because
there's
also
the
signing
process.
Somebody
has
to
sign
your
workload.
A
Somebody
has
to
look
at
what
CA
should
I
use
for
signing,
because
all
of
those
things
that
has
to
happen
before
that
ID
is
generated
rather
those
PPS
code
is
generated,
so
that,
essentially,
is
something
that
is
happening
with
with
something
referred
to
as
a
workload
API.
The
last
one,
which
is
also
important,
is
the
notion
of
trust.
Bundles
trust,
bundles,
essentially
represents
from
a
x59s
switch
perspective,
a
collection
of
roots
years
right.
So
that's
what
I
did.
A
A
That's
basically
what
spiffy
Basics
are
basically
all
of
this
in
some
way
or
the
other
map
to
things
that
you're
doing
whether
you're
deploying
your
workload,
whether
you're
deploying
you
know
any
other
application
things
to
think
about
is
from
a
perspective
of
spiffy
is
understanding.
What
are
these
various
elements
that
you
deal
with?
A
Obviously
you
know
we
go
from
here
to
ensure
that
you
know
everything
can
be
absolutely
automated.
These
things
are
automatically
generated.
These
things
are
automatically
managed,
that's
essentially
what
we
want
to
do,
and
from
that
perspective,
the
other
project
that
I
want
to
talk
about
is
cert
manager.
A
Cert
manager
is
something
that
many
of
you
use
many
of
your
familiar,
essentially
something
that
allows
you
to
automate
provision
manage
TLS
certificates
at
scale.
People
use
it
for
their
ingresses
people,
use
it
to
mount
it
to
their
parts.
People
use
it
in
the
context
of
anything
that
requires
a
TLS
certificate
that
will
allow
you
to
securely
provide
access
to
your
application,
something
that's
very
commonly
used,
and
there
are
several
add-ons.
You
know.
One
of
the
things
that
we
talk
about
very
often
is
only
search
manager.
A
Cert
manager
has
a
lot
of
supporting
add-ons,
I,
usually
call
them
cert
manager
and
friends,
because
these
friends
essentially
allow
you
to
build
much
more
robust
capabilities
for
your
security
infrastructure
within
kubernetes
and
and
then
we'll
talk
about
some
of
those.
Some
of
those
friends,
as
we
sort
of
you
know,
get
through
the
rest
of
the
presentation
we
are
now
in
incubating,
so
this
was
announced.
Obviously,
you
know
just
two
or
three
weeks
ago:
cert
manager
is
now
an
incubator
within
the
cncf
ecosystem.
A
We
have
a
lot
of
maintainers
actually
here
in
Detroit.
So
if
you
haven't
visited
the
search
manager
booth
at
the
Pavilion,
please
do,
and
we
can
talk
a
little
bit
more
about
you
know
what
this
or
WhatsApp
manager
does
and
at
the
top
of
the
top
of
the
title,
you
will
see
me
adding
a
few
of
those
pluses
and
that's
intentional,
because
I'm
actually
building
some
additional
add-ons
and
and
I
spoke
about
friends.
These
friends
essentially
will
provide
you.
A
The
ability
to
sort
of
you
know
do
additional
capabilities,
so
we
talked
about
assert
manager
set
manager.
Csi
driver
spiffy
is
essentially
a
CSI
plugin,
a
driver
plug-in
that
allows
you
to
basically
make
sure
that
you
know
you
have
an
automated
way
of
injecting
spiffy
as
switch
to
your
workloads
that
your
workloads
can
use
a
simple
way
of
thinking
about
it.
Is
you
know,
anytime?
You
need
an
x59
certificate
to
be
mounted
in
a
part
that
is
spiffy
a
squid
that
is,
then
you
just
use
PV
drivers,
the
CSI
driver
spiffy.
A
All
you
do
is
in
your
deployment
specification,
you'll,
add
some
volume
attributes
and
then
automatically
you
will
have
a
certificate
injected
into
it.
The
the
second
add-on
that
I'm
going
to
talk
about
is
trust.
Trust
manager
is
a
is
a
project
that
is
part
of
cert
manager,
essentially
to
help
distribute
trust
or
distribute
cross
bundles,
so
to
speak.
So
if
you
go
back
to
the
definitions
that
we
draw
for
spiffy,
we
talked
about
some
of
these
things.
A
The
third
one
is
is
also
a
most
important
sort
of
a
add-on,
which
we
call
obviously
the
approved
policy,
the
if
you
are
familiar
with
cert
manager
and
if
you
have
used
search
manager.
One
of
the
things
you
probably
have
seen
is
every
time
a
Certificate
request
resource
is
created.
There
are
certain
properties,
there
is
an
approved
denied,
ready
and
I
would
say
99
of
you.
A
However,
from
the
perspective
of
spiffy
s,
wait,
there
are
certain
things
in
the
specification,
so
the
list
that
you
see
there
is
actually
from
the
spiffy
specification
that
every
X-File
9
s
Wade
needs
to
have
certain
character.
Specs
and
those
characteristics
are
defined
there
and
what
we
provide
as
part
of
the
CSI
driver
is
an
additional
controller,
a
policy
approval
controller
that
is
allowed
that
ensures
that
every
time
an
S
Suite
is
generated,
it
complies
automatically
to
the
specification
defined
by
these
defined
by
spiffy.
So
you
don't
have
to
write
a
policy.
A
You
don't
have
to
write
your
own
or
author
policies.
This
is
automatically
built
into
the
CSI
driver,
specific
plugin,
so
it
ensures
that
every
single
certificate
that's
generated,
complies
to
those
those
properties
that
you're
defined
there.
So,
from
the
perspective
of
the
solution,
I
just
wanted
to
walk
through
and
I
spoke
about.
You
know
a
bunch
of
things
and
I
talked
about.
You
know
all
of
them
in
an
individual
way.
A
If
you
sort
of
look
at
it
at
a
at
a
at
a
view
from
where
you
have
to
think
about
how
all
of
these
work
together,
what
you
really
have
is
a
bunch
of
different
components
that
cert
manager
there
you
see
policy
approval,
you
see
the
trust
manager,
obviously
CSI
driver
I'm,
representing
down
here
primarily
because
it's
a
demon
set.
It
is
attached
to
you,
obviously
node
and
and
every
time
a
part
is
scheduled
to
the
node.
Basically
CSI
driver
says
okay,
so
party
schedule.
A
A
Those
are
the
specific
things
that
sort
of
you
know
happen
and
and
as
soon
as
that,
as
soon
as
that
process
is
over,
the
CSI
driver
plug-in
essentially
initiates
a
request
to
search
manager
with
the
CSR
that
CSR
contains
a
certificate
with
that
specific
properties
that
we
just
saw
in
the
previous
slide.
It
carries
all
of
the
information
about
your
workload.
It
carries
all
of
the
information
about
the
service.
A
Is
you
know,
basically
that
CSR
was
generated
and
once
that
happens,
cert
manager
does
the
certificate
reconciliation.
It
goes
to
the
process
of
ensuring
that
you
know
that
certificate
is
going
to
be
fulfilled.
Part
of
that
it
also
has
to
make
sure
that
you
know
the
trust
and
everything
is
is
generated.
Rather
all
of
the
trust
bundle
that
was
created
is
distributed.
Back.
I
spoke
about
the
policy.
It
ensures
that
you
know
you're
not
creating
some
certificate
by
hand
using
the
issuer.
A
That
is
tied
to
your
specific,
because
there
is
the
notion
of
an
issuer
tied
back
to
your
organization
CA,
which
could
be
backed
by
the
security
teams,
managed
HSM
or
whatever.
That
might
be
right.
So
after
this,
obviously
it's
basically,
you
know
just
mounting
the
CR
mounting
the
certificates.
Basically,
the
TL
assert
the
private
key,
the
ca
cert.
All
of
these
things
that
needs
to
be
available
for
the
part,
specifically
in
that
war
run
secret
spiffy.io.
You
will
have
all
of
these
things
readily
available
there
and
then
please,
all
one.
A
These
are
all
automatically
mounted.
So
it's
it's
available
for
for
this
specific
driver
to
for
the
rather
the
part
to
be
to
use
that
application
or
use
that
as
weight
whenever
it
talks
to
other
applications.
So
you
can
imagine
that
you
know.
If
you
have
this
one
single
deployment,
a
replica
of
five,
every
single
one
of
them
has
a
uniquely
cryptographically,
verifiable
x509
s.
A
Word
mounted
on
the
volume
Mount
of
that
specific
part,
because
when
those
parts
talk
to
other
parts
or
if
you're
talking
to
other
things,
every
one
of
them
have
an
identity
and
your
communication
is
is
built
on
the
principle
of
mutual
authentication,
Mutual
DLS
last
step.
Obviously
you
know
just
as
we
talked
about
you
know
you
deploy.
Of
course
you
aren't
deploy
or
you
delete
parts
and
you
destroy
Destroyer
duplicate,
because
you're
probably
going
through
the
cycle
of
deployment
continuously
and
when
such
a
thing
happens.
A
Obviously,
you
know
all
of
the
certificate
material
that
is
associated
with
that
workload
is
gone.
You
destroy
it
because
one
of
the
things
that
you
may
be
familiar
with
you
know
when
you
create
a
certificate
resource
using
search
manager.
There
is
a
TLS
secret
that
is
automatically
created
with
the
case
of
spiffy
driver.
There
is
no
TLS
secret
because
all
of
the
material
that
is
required
for
that
part
is
actually
injected
into
the
volume
Mount
and
that
would
that
part
is
deleted.
It
goes
away.
A
So
there
is
no,
you
know
TLS
secrets
to
manage
TLS
ticket
to
track
off.
You
know
TLS
tickets
to
our
back
on
and
also
from
a
security
standpoint.
You
know
some
of
the
some
of
the
larger
financial
institutions
have
have
have
have
at
least
guidelines
around,
not
creating
any
killer
Secrets,
especially
that
that
has
private
keys
and
things
like
that
in
their
in
the
material.
A
So
this
sort
of
you
know
addresses
that
that
that
notion
of
an
identity
that
is
issued
to
a
workload
when
it
needs
it
where
it
needs
it,
so
that
the
other
workloads
when
they
are
in
communication,
they
are
all
mutually
talking
to
each
other.
That's
the
sort
of
a
sort
of
the
high
level
view
of
you
know
how
all
of
these
things
work.
Obviously
there
is
specific
inward
here.
There's
the
self
manager
involved
here,
cert
manager,
CSI
spiffy
driver,
is
involved
here.
Trust
manager
is
involved.
Policy
approach,
isn't
all
lots
of
different
projects.
A
All
sort
of
you
know
coming
together
to
provide
this
ability
to
to
help
sure
that
you
know
you
are
securing
your
workloads,
irrespective
of
where
they
are
running
so
so
the
idea
is
that
you
know
you're
not
just
using
one
single
component
you're
using
a
combination
of
things
to
help
satisfy
that
security.
Aspects
of
you
know
how
you
secure
workloads
so
I
want
to
now
hand
it
off
to
to
riyaz
to
to
talk
a
little
bit
about
the
demo
architecture.
A
B
A
B
So
for
our
demo
architecture,
we
have
a
cluster,
that's
running
on
k3s,
it's
a
two
node
cluster,
that's
running
on
Raspberry
Pi,
and
then
this
is
where
all
your
client
workloads
are
going
to
be
or
your
Edge
workloads
are
going
to
be
running.
And
now
we
have
another
cluster,
which
is
a
six
node
gke
cluster.
That's
running
in
the
cloud
we
have.
B
So
what
you
see
here
in
the
middle
are
all
components
that
sitram
already
talked
about:
cert
manager,
SPV
driver
policy,
approver
trust-
and
these
are
all
installed
in
both
the
edge
as
well
as
the
gke
cluster.
So
what
really
happens
right?
So,
let's,
let's
look
at
a
server
side
component
or
a
server-side
microservice,
that's
deployed
on
the
gke
cluster.
B
The
CSI
spiffy
driver
sends
a
CSR
set
manager
receives
it
and
it
creates
a
Certificate
request.
Now.
This
is
Certificate
request
policy
that
is
bundled
into
the
policy
approver
the
policy
approver
and
approves
the
policy
cert
manager,
a
cert
manager
means
a
x509
s
with
and
then
mounts
it
onto
the
volume
of
the
workload.
B
Now
this
happens
in
both
the
server
as
well
as
the
client.
So
each
one
have
their
own
machine
identity.
Now
now?
What
about
trust?
How
do
they
talk
talk
to
each
other
right?
So
that's
where
the
trust
bundle
comes
in
the
trust
bundle
yeah,
so
the
trust
bundle
is
distributed
across
both
the
Clusters
which
have
the
cas.
So
if
you
look
at
next
slide,
you
would
see
that
the
clients
here,
as
well
as
the
service
CA,
is
within
the
plus
bundle
that
is
distributed
in
the
gke
cluster.
So
this
basically
creates
trust.
B
Now,
once
you
want
to
revoke
trust,
what
you
do
is
remove
the
ca
from
the
trust
bundle
in
your
service
server
application.
Oh
sorry,
in
your
server
cluster.
This
basically
revokes
the
trust
between
the
two
workloads.
So
it's
like
pretty
simple
you're
not
going
across
doing
East-West
traffic
and
you
you
you're
both
revoking
trust
as
well
as
yeah
you're,
enabling
Trust.
B
Using
Helm
on
my
gke
cluster,
now,
what
I'm
going
to
do
is
I'm
going
to
create
an
intermediate
certificate.
Now
in
you,
you
would
be
creating.
We
are
creating
this
certificate
just
for
demos
for
demo
purposes,
but
then
you
would
be
using
your
pki
infrastructure
to
issue
the
certificate
and
search
manager
would
do
that
for
you
right
now.
This
creates
a
certificate
with
the
certificate
contents,
as
well
as
an
issuer
that
is
used
to
serve
the
trust
domain.
B
B
And
when
I
see
the
contents
of
the
trust
bundle,
I
would
see
both
the
certificate
of
the
cas.
The
ca
certificate
for
the
client,
as
well
as
the
server
now
I'm
going
to
deploy
the
CSI
spiffy
driver,
and
this
I
see
that
I'm
already
talked
about
it's
a
demon
set.
So
this
may
take
some
time
because
okay.
B
B
I'm
going
to
be
switching
to
that
context,
and
here
I've
installed
all
the
the
set
manager,
the
trust,
the
trust
project,
the
CSI
spiffy
driver
and
all
of
that.
So
that's
what
you
see
here
and
let
me
go
in
and
see
my
CS
again
I
created
my
trust
already.
This
has
all
my
trust,
bundles
that
are
synced
across
my
workspaces,
and
here,
if
you
see
it
has
both
the
CA
and
the
servicer
now
I'll
deploy
my
client
application.
B
B
So
what
you
see
here
is
the
client,
the
client
application
that's
running
on
my
Raspberry
Pi
is
talking
to
my
to
my
server
application,
that's
running
on
the
gke
cluster,
and
this
is
there's
a
handshake.
There's
an
mtls
handshake,
that's
happening
and
we're
getting
a
edge
activated
message
here.
You
can
also
I
have
another
one
called
HP.
B
B
B
B
A
A
I
wanted
to
give
a
shout
out
to
you
in
a
couple
of
our
colleagues.
You
know:
we've
been
working
on
this
for
a
long
time,
especially
Josh,
who
is
also
here.
If
you
want
to
spend
time
talking
to
him
about
several
other
add-ons
for
cert
manager,
he's
the
one
who
built
spiffy
part
of
jetstack
there's,
also
a
much
more
detailed
blog
about.
You
know
how
to
manage
workload.
A
Identities
across
multiple
different
Cloud
providers
feel
free
to
reach
out
that
thing
as
well
and,
most
importantly,
one
of
the
things
that
we've
spent
time
in
the
last
I
mean
obviously
a
few
months,
and
you
know
at
least
a
couple
of
years
or
so
freely
leading
reading
solving
the
bottom
total.
So
if
you
haven't
read
this
book,
I
strongly
recommend
you
going
through
this,
because
this
essentially
talks
about
a
lot
of
different
things
that
we
just
covered,
but
also
in
a
much
more
detail,
also
going
behind
spiffy
into
the
world
of
spire.
A
A
I
want
to
also
to
make
sure
that
you
know
if
you,
if
you
are
somebody
who
uses
search
manager.
Obviously
we
talk
about.
You
know
TLS
as
digital
identities.
If
you
want,
you
know,
Wax
Seal,
printed
physical
certificate
that
we
want
to
carry
with
you
come
see
us,
so
we
are
actually
a
minting
certificate
by
hand
with
a
wax
seal,
and
you
know
we'll
give
one
to
you
that
you
can
take
as
a
souvenir
so
visit
us
at
our
birth.
So
that'll
give
you
something
that
to
take
forward
as
well.
A
So
so,
where
do
we
leave
from
here
so
I
mean?
Obviously
you
know
we
showed
some
of
the
things.
That's
possible,
there's
also
a
lot
of
things
that
we
can
work
on.
Some
of
the
things
that
we
identified
that
that
absolutely
needs
to
be
done
is
a
model
driven
way.
So
today
we
saw
that
you
know
there
were
some
things
that
we
were
doing,
obviously
managing
trust.
You
know
in
a
way
where
we
are
where
you're,
creating
this
resource
called
bundle
and
managing
it.
A
So
we
won't
be
able
to
model
that
via
rules
and
things
like
that,
that's
something
that
we've
been
thinking
about,
obviously,
in
a
trust,
distribution
of
cross
trust
boundaries
is
also
something
that
that
we
want
to
look
at
in
an
automated
way
today.
You
know
there
is
you
have
to
you
can
manage
it,
but
you
know
you
can
you
can
literally
have
to
you
have
to
figure
out.
You
know
how
to
how
to
distribute
trust
across
multiple
different
things,
but
then
again
you
know
we
also
look
at
you
know.
A
What
does
it
mean
to
have
control
plane
that
we've
been
working
on
to
essentially
manage
trust
across
different
security
boundaries
and
how
you
manage
it?
How
do
you
get
it?
That's
where
we
are?
Obviously
you
know
there
is
a
QR
code
to
sort
of
you
know,
provide
you
feedback.
We
appreciate
any
feedback
that
you
might
have
talk
about
it
and
we
can
take
questions
if
you
have.
C
D
How
does
this,
how
does
the
the
cert
manager
model
for
this
process
that
you've
laid
out
here?
How
does
this
interact
with
doing
mtls
through
a
service
mesh,
which
is
another
approach
that
I've
seen
to
doing
this
is
this?
Is
this
you
know,
is
this
something
that
that
plays
with
that,
or
is
this
kind
of
in
place
of
doing
that
through
through
a
service
mesh?
How
does
how
does
that
interact?
Absolutely.
A
So
we
do
have
Integrations
with
service
mesh,
so
there
are
different
service
measures.
That
sort
of
you
know
like,
for
example,
if
you're
using
istio
there
is
an
add-on.
That's
specifically
is
called
istio
CSR
that
essentially
mounts
cert
manager
as
a
way
to
provide
that
workload
signing
certificates
into
istioid.
So
that
way,
any
of
the
any
of
the
workloads
that
is
part
of
your
mesh
will
essentially
be
delegated
to
be
signed
by
the
signing
certificate
that
is
managed
by
search
manager.
So
that's
what
istia
CSR
does.
A
It
is
an
add-on
that
you
would
install
in
your
in
your
cluster
wherever
your
service
meshes,
but,
as
you
sort
of
you
know,
manage
your
service
mesh,
you
would
essentially
not
use
the
default
built-in
CS
server
or
this
mechanism
through
which
the
ca
is
used,
but
but
the
but
the
the
mechanics
of
search
manager
essentially
enables
you
to
plug
your
organization
CA
into
the
signing
process.
So
it
is
possible.
So
obviously,
CSI
driver
and
CSI
species
used
more
in
the
context
of
non-mesh
workloads,
but
for
West
workloads.
There
is
absolutely
that
mechanism
available.
C
A
A
Yeah,
so
the
idea
is
that
you
know
the
trust,
domains
are
across
clusters
and,
and
we
want
to
be
able
to
distribute
and
manage
trust
across
trust
boundaries
today
that
management
of
trust
across
that
is
via
a
trust,
bundle
that
you
distribute
with
it
with
the
cas
that
you
manage
and
that's
essentially
connects
the
the
trust
stores
or
the
trust
Cas
or
the
cas
that
you're
managing
across
multiple
different
clusters
to
communicate
with
each
other.
So
in
this
example,
we
were
using
a
multi-cluster
model
to
distribute
Trust.