►
Description
Service Mesh Hub is a Kubernetes-native management plane that enables configuration and operational management of multiple heterogeneous service meshes across multiple clusters through a unified API.
Service Mesh Hub simplifies discovery, trust domain unification, access policy, and L7 traffic routing among other things.
In this demo, we look at unification of identity and trust domain across multiple meshes.
A
Thanks
again
for
stopping
by
our
youtube
channel,
this
is
Christian
posta
from
soulard
nao.
This
is
a
continuation
of
a
series
of
demos
where
we
dive
into
service
mesh
hub
and
its
capabilities.
In
the
previous
demo,
we
saw
its
ability
to
discover
clusters
and
meshes
and
workload
items
that
are
running
inside
of
those
particular
meshes,
and
specifically,
we
started
with
two
steel
clusters
now
in
this
demo.
A
What
we're
gonna
do
is
we're
going
to
take
a
look
at
federating,
the
root
identities
across
the
two
different
meshes,
because
they
start
it
off
to
spare
it
we're
gonna,
bring
them
together
so
that
we
can
route
traffic
across
them
in
the
next
video,
we'll
look
at
using
a
unified
API.
On
top
of
this
new
virtual
mesh
and
control
things
like
access
policies
and
network
routing
and
so
forth.
So
let's
get
started
just
to
remind
you.
A
A
A
A
Now,
what
we're
going
to
do
using
service
mesh
hub
is
unify
them
using
a
a
contract
called
the
virtual
mesh
we're
going
to
group
them
into
a
single
logical
mesh,
and
we
can
see
that
here,
the
virtual
net,
using
the
virtual
mesh
CRD,
we're
going
to
say,
generate
a
route
that
will
be
the
root
of
both
of
the
meshes.
If
we
already
have
a
CA
a
root
CA,
we
could
specify
it
here
in
this
case,
will
generate
one
we're
going
to
federate
the
meshes
and
make
them
permissive
to
start
off
with.
For
this
demo.
A
Permissive
just
means
that
the
service
discovery
between
the
two
services
will
be
global.
So
you
can
see
all
the
services
in
clubs
are
two
and
in
cluster
one
we're
going
to
start
off
by
not
enabling
access
control.
So
everything
can
talk
to
everything,
we'll
see
that
in
the
next
demo-
and
these
are
the
meshes
that
we
are
going
to
group.
A
So
let's
apply
this
virtual
mesh
and
you
can
see
we're
applying
it
to
cluster
1,
which
is
where
the
management
plane
here
lives
the
service
mesh
hub.
So
that
says
it
was
created.
Now
if
we
go
and
get
this
resource,
we
should
see
the
same
thing
that
we
expected,
but
then
in
the
status
field-
and
this
is
actually
important
detail
too.
All
of
the
service
Mashhad
resources,
there's
a
status
field-
gives
information
about
the
the
state
machine
behind
it
right
now,
except
the
acceptable
transitions
and
their
their
states.
A
We
can
see
everything
that
was
accepted
here.
So
that's
good.
Now,
we've
created
this
virtual
mesh
abstraction.
Let's
take
a
look
at
the
secrets
that
were
created
right,
so
we
asked
a
service
mesh
hub
to
automatically
create
this
route
CA,
and
we
can
see
that
here
and
let's
take
a
look
at
that
particular
route
CA
and
let's
take
a
look
at
the
certificate
itself,
so
we
can
see
here,
let's
actually
copy
this.
It
ends
in
ns
I
with
the
equal
sign.
That's
just
those
copy
it
here.
A
So
we
have
it
yep
that
so
now,
when
we
created
this
virtual
mesh,
what
this
instructed
the
service
must
have
to
do
is
ask
each
cluster
each
service
mesh
to
generate
its
own
keys
and
an
certificate
and
certificate
signing
request
that
will
act
as
intermediate
and
form
a
chain
between
what's
running
in
the
particular
clusters
and
ultimately,
this
root
CA
that
we
created.
So
we
can
see
if
we
ask
for
the
the
virtual
mesh
certificate
signing
request.
A
We
can
see
that
on
cluster
2,
it
also
exists
on
cluster
1
and,
let's
actually
take
a
look
at
this
see
a
whole
bunch
of
stuff.
Here
here
is
the
the
the
host
name
and
the
and
the
org
for
which
we
want
this
certificate
signed.
The
csr
data
here
is
base64-encoded,
but
we
can
see
in
the
status
field.
Like
I
mentioned
the
response,
so
we
have
the
CA
signed
and
we
have
the
route
that
was
used
in
this
particular
chain.
Again,
it's
base64
we'll
take
a
look
at
it
in
a
second
now.
A
What
this
means
is:
we've
created
a
new
key
and
certificate
pair
on
each
of
the
meshes
without
transmitting
any
keys
or
certificates
across
the
network
other
than
the
certificate
signing
request,
and
we
can
see
that
in
cluster
1
we
created
a
see
a
search
for
Sto
and
in
cluster
2.
We
did
the
same
thing
now.
If
we
look
at
the
root
cert
from
our
from
the
see
a
search
that
was
created,
we
can
see
NS
I
with
the
equal
sign
and
that
matches
what
we
expected
from
our
root
search
from
service
mesh
hub.
A
So
let's
bounce
the
ischial
pods,
the
the
SPO
control
plane,
and
at
the
moment
we
we
need
to
do
that
because
it
doesn't
pick
it
up
automatically.
Let's
do
that
on
cluster
1
and
cluster
2.
That
is
something
that
we
are
working
on
at
Isola
will
contribute
that
to
to
SDA.
Let's
get
down
that
working
and
then
another
thing
that
we'll
notice,
if
we
come
over
here,
real
quick,
is
that
the
I've
also
restarted
the
workload
so
that
they
pick
up
the
new
certificate
chain.
It
eventually
does
happen,
but
it
it
takes
a
little
bit.
A
A
Where
is
the
root?
The
root
is
right
here
and
we
can
see
NSI
does
that
match?
Yes,
it
does
so
now.
Our
trust
domain
on
the
first
cluster
is
anchored
on
the
root
CA
that
we
generated
for
service
mission
with
service
Mashhad.
Let's
take
a
look
at
cluster
to
do
the
same
thing
come
up
here
and
look
at
the
root
certificate
in
the
chain.
We
see
NSI
and
again
that
matches
so
now
both
clusters
are
federated
in
terms
of
their
trust
amis.