►
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 a multi-cluster, virtual-mesh API for managing access control policies.
A
In
the
previous
two
videos,
we
saw
how
to
discover,
meshes
and
work
items,
workload
items
inside
those
meshes
and
we
also
saw
how
to
unify
their
trust
domains
so
that
services
can
call
each
other
and
validate
each
other's
identity
using
the
same
trust,
Amin
root,
trust
and
in
this
video,
we're
gonna
take
a
look
at
is
now
that
we
have
this
virtual
mesh
concept
and
we
can
treat
multiple
installations
of
a
service
mesh
as
a
single
mesh.
How
can
we
write
policies
like
access
control
policies
and
networking
network
routing
policies
against
this
one
unified
mesh?
A
A
So,
let's
take
a
look
at
this
functionality,
so
the
first
thing
we're
gonna
do
is
port
forward
to
our
product
page,
so
we're
following
the
book
info
demo
from
the
sto
repo
and
in
the
previous
demos
we
showed
we
had
some
of
the
components
of
book
info
deployed
on
the
cluster
one
specifically
the
product
page
details,
reviews
one
and
refused
to
on
closer
to.
We
have
reviews
three
all
right.
So
if
we
come
to
the
browser
here
and
we
go
to
a
local
host.
A
Can
click
here
and
we
see
and
we
refresh
a
couple
times-
we
see
that
it
will
load
balance
between
version,
1
and
version
2
of
reviews
and
that's
fine.
So
what
we
want
to
do
here
is
enable
access
policy
on
the
virtual
mesh
in
the
first
iteration.
We
had
this
set
to
false,
but
here
we're
going
to
set
it
to
true.
A
We
leave
everything
else,
the
same,
the
number
of
meshes
that
have
been
grouped
the
Federation
mode,
shared
identity
and
the
built
in
certificate
authority
generation
that
we
used
for
generating
the
routes
yay,
but
will
enable
the
enforce
access
control
flag.
So
let's
apply
that
now
by
default
with
this,
do
when
we
enable
the
authorization
policies
in
this
what's
happening
under
the
covers,
it
is
a
default
deny
all.
A
So
once
this
has
been
created,
then
we
come
over
here
and
refresh
product
page
should
not
be
able
to
call
into
details
and
product
reviews
book
reviews,
and
we
see
that
we
are
getting
some
requests
blocked
and
it
does
take
a
little
bit
of
patience
until
it
finally
settles
in
in
issue,
and
now
we
see
that
on
successive
refreshes
that
indeed
we
cannot
reach
product
details
and
product
review.
So
that's
that's
a
default.
So
now,
let's
look
at
the
authorization
policies
that
were
created
under
the
covers.
We
can
see
a
global
access.
A
Control
was
created
and
if
we
take
a
look
at
this,
we
can
just
see
this.
This
is
the
default
empty
spec,
which
means
block
everything.
So
this
blocks
everything
trying
to
communicate
in
the
mesh,
whether
that's
in
cluster
1
or
cluster
2,
right,
like
I,
said
the
authorization
policy
and
what
we'll
see
in
the
next
video
Network
policy
these
these
consider
the
entire
mesh
through
the
virtual
mesh
definition
that
we
have
so
now,
let's
enable
some
traffic.
Let's
take
a
look
at
this
access
control
policy
that
manages
control
over
multiple
clusters.
A
In
this
case,
the
spec
generally
follows
a
source
and
destination,
so
you
can
select
mul
of
all
different
sources,
using
labels
and
namespaces,
as
well
as
multiple
different
destinations,
which
would
be
services
following
the
same
patterns
right.
So
you
don't
you
can
you
can
treat
multiple
different
workloads
at
the
same
time
with
a
single
access
control
policy.
So
in
this
case,
what
we're
saying
is
for
the
product
page
service
account
running
on
cluster,
one
that
can
talk
to
anything
running
in
the
default
namespace,
regardless
of
what
cluster
it
lives
in.
A
So
let's
apply
this
product
page
policy,
okay,
so
yeah,
just
like
we
saw
with
how
it
became
enabled.
We
should
see
some
jitter.
It
should
take
a
little
bit
for
it
to
come
back
alive
and
when
it
does
come
back
alive,
we
can
see
that
book
book
details
that
comes
in
reviews,
reviews
v2,
tries
to
call
out
two
ratings
and
we
can
see
that
we
can't
call
ratings.
A
We
still
have
our
access
control
set
to
deny
all
all
we've
said
was
that
product
page
can
talk
to
anything
in
the
default,
but
it
didn't
in
the
default
namespace.
It
didn't
say
anything
about
those
services
talking
to
anything
all
right.
So
let's
also
take
a
look
at
the
access
policy,
so
that
reviews
running
in
cluster
one
can
talk
to
ratings
which
might
be
running
in
any
cluster
on
at
the
default
namespace.
A
And
give
this
a
refresh
now
for
review.
We
should
start
to
see
stars
right
so
when
we
call
in
to
reviews-
and
it
gets
two
reviews-
v2
that
will
call
ratings
and-
and
we
do
get
the
stars
as
we
expected.
So
this
access
control
policy
is,
like
I,
said,
a
virtual
match,
aware
policy
and
kind
of
simplifies
the
mechanics
of
managing
multiple
different
sources
and
destinations
and
writing
a
single
unified
policy
for
for
all
of
them.
So
that's
it
for
this
one,
this
video
in
the
next
video.