►
From YouTube: Establish a common root trust across Istio clusters
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
A
To
allow
communication
across
clusters,
we
need
to
have
a
common
root,
CA
used
to
generate
the
certificates
of
the
different
workloads
by
default.
When
you
deploy
the
istio
control
plane,
the
cluster
is
going
to
Auto,
generate
a
CA
certificate,
which
is
which
it's
going
to
use
to
sign
the
certificate
for
the
local
workloads
and
the
second
cluster
here
with
the
workloads
are
going
to
do
the
very
same.
A
So
these
CA
certificates
have
nothing
to
do
with
one
another
and
in
actuality
that
prevents
these
workloads
from
being
able
to
communicate
across
these
clusters.
So
you
need
to
have
this
common
root,
CA
or
intermediate
CA
used
to
generate
the
intermediate
CA
of
each
cluster.
That
is
then
going
to
be
used
to
generate
the
workload
certificates.
A
You
can
do
that
manually
by
creating
all
these
certificates
and
distributing
these
certificates
in
the
different
clusters
by
creating
the
different
secrets
in
glue
mesh.
We
have
this
ability
to
automate
this
process
using
multiple
different
architectures,
while
also
providing
the
ability
to
rotate
these
certificates
here.
What
we're
going
to
do
first
is
to
look
at
what
we
have
right
now,
if
I'm
on
cluster
one.
A
The
ca
certificate
that
you
see
in
one
of
the
Clusters
or
cluster
one,
the
last
line
starts
with
r
v
r.
U
l,
the
second
cluster
doesn't
have
this,
so
the
cluster
cluster
2
has
nothing
that
will
has
nothing
effectively.
That'll
prevent
the
communication
between
the
Clusters.
So
what
we'll
have
to
do
here
is
create
this
root.
Truss
policy-
and
we
say
we
want
this
root
C8
to
be
auto-generated,
so
that
we
want
these.
We
want
to
restart
the
pods
automatically.
A
So
that
they
start
to
use
the
new
certificates,
it's
just
like
avoiding
waiting
for
these
pods
to
request
the
new
certificate
to
the
control
plane.
Obviously,
in
production
you're
not
going
to
enable
this
Auto
restart
and
you're
not
going
to
use
an
auto-generated
certificate,
you
are
going
to
provide
the
certificate
as
a
secret
or
you
could
use
glue
platform
integration
with
multiple
different
Cloud
providers
to
get
certificates
in
various
ways.
A
A
A
A
So
if
we
look
at
this
right
now,
we
can
see
that
all
of
these
different
services
are
actually
being
restarted
right
now,
if
I
go
back
here,
it's
a
little
bit
like
explaining
the
way
it
works.
So
basically
there
is
a
CSR
that
is
created
by
the
agent,
a
certificate
signing
request
that
is
created
by
the
agents
to
request
the
intermediate
certificate
for
the
local
cluster.
Then
it's
going
to
store
this
intermediate
CA
as
a
secret.
A
A
You
see
here
is
on
the
last
line,
it's
starting
with
eight
zero
U
and
if
I
look
at
the
second
cluster
and
again,
if
I
decide
to
send
another
request
again
from
the
review
service
over
to
the
rating
service
on
the
other,
cluster
I
will
see
on
that
last
line.
Eight
zero
start
at
the
starting
now
they're
using
different
intermediate
certificates,
but
they
are
issued
from
the
same
root
CA.
So
this
cross-cluster
communication
will
be
possible.
A
What
you
can
do
is
that
you
can
also
get
the
certificate
stored
in
the
file
and
then
by
decrypting
any
of
these
certificates
with
any
tool.
You
should
be
able
to
see
some
information
about
the
workload
itself,
so
basically,
the
certificate
is
the
one
created
by
the
rating
service
that
will
allow
the
rating
service
to
prove
its
identity
to
other
services.
A
We
use
the
spiffy
ID
and
can
see
that
in
that
spiffy
ID
we
have
a
cluster
name,
the
namespace,
the
service
account,
and
because
of
that
it
gives
a
unique
identity
for
each
service
account
globally.
We
have
one
service
that
is
called
in
mesh
and
it's
not
part
of
any
workspace.
So
it's
not
going
to
be
restarted
automatically
and
at
the
end
of
this
video.
That's
why
I'm
going
to
go
ahead
and
restart
this
service.