►
From YouTube: Role Based Access Control for Multi-Cluster Service Mesh
Description
Learn more about delegating access and ownership of service mesh APIs to different personas like developers, Admins, and SREs.
About Gloo Mesh
https://solo.io/products/service-mesh-hub
Questions? https://slack.solo.io
A
Hi
everyone
in
this
video
I'm
going
to
show
you
a
new
feature
coming
with
glue
mesh
enterprise,
which
is
focusing
on
hair
back
and
especially
how
you
can
manage
airbag
across
multiple
clusters,
where
you
have
service
mesh
deployed.
So
before
we
start,
let's
go
through
different
options.
You
have
when
it
comes
to
airbag
on
kubernetes
and
then
on,
and
then
what
other
challenges
when
we
start
to
deploy
istio
and
multiple
clusters.
A
So,
first
of
all,
on
the
kubernetes
side,
you're,
probably
all
aware
of
the
way
airbag
works,
you
can
create
these
holes
and
cluster
holes
and
roll
binding
and
cluster
hole.
Binding,
very
common
use
case,
for
that
is
when
you
want
to
share
the
same
cuban
cluster
with
multiple
teams.
You
generally
create
a
role
for
each
team.
So
that's,
basically
each
team
gets
his
own
namespace
and
they
become
like
namespace
admin.
So
there
is
no
impact
on
when
one
team
does
on
another
one.
A
So
you
can
create
these
roles
like
that,
and
you
say:
okay,
that's
a
role
that
gives
permissions
on
all
the
api
groups
that
are
part
of
the
core
kubernetes,
and
then
you
define
the
resources.
So
if
it's
a
namespace
admin,
for
example,
would
be
any
resource
and
any
verb
in
the
namespace,
and
then
you
do
like
a
whole
binding
where
you
attribute
the
namespace
admin
role
to
a
user
of
or
group
of
users.
A
So
that's
the
way
you
you
generally
handle
hair
back
in
kubernetes.
When
you
start
to
use
istio,
then
you
can
start
to
use
to
create
additional
objects
that
are
not
part
of
the
core
kubernetes.
What
we
call
custom
resource
definitions,
you
can
create
authorization
policies,
but
authorization
policy
has
nothing
to
do
with
airbag.
It's
just
like
a
way
for
you
to
say:
okay,
this
service
is
allowed
to
talk
to
this
service.
It
doesn't
allow
you
to
specify
that
user
can
create
this
authorization
policy
and
automation.
A
Policy
is
just
one
example,
but
you
have
also
virtual
services.
You
know
like
these
are
the
ones
for
security,
and
then
they
have
the
one
for
traffic
management.
So,
basically,
if
you
want
to
determine
who
can
create
these
objects,
then
you
need
to
use
the
traditional
cubans
airbag.
So
here,
instead
of
just
saying
like
the
api
group,
is
double
quote:
double
quote
right,
which
means
like
any
core
api
group.
You
would
do
like
comma
and
then
the
api
group
of
these
different
objects.
A
For
example,
you
could
do
api
group
security.eto.io
v1
beta1,
which
is
the
one
where
you
have
this
different
security
object,
and
you
would
do
the
same
here.
If
it
comes
through
virtual
services,
there
will
be
networking.co.io,
so
you
could
create
different
rules
here
with
these
corresponding
api
groups
and
different
resources,
and
you
could
say:
okay,
this
user
can
create
this
kind
of
object
there.
A
But
you
cannot
go
really
fine
grain.
You
can
just
tell
if
they
can
create
or
not
these
objects,
but
you
cannot
define
what
information
they
put
in
this
object.
So
if
someone
creates
a
virtual
service
and
then
decide
to
root
that
to
a
specific
service,
you
cannot
determine
or
you
cannot
define
airbag
holes
that
will
prevent
that
person
to
do
that.
It's
either
you
let
him
create
these
virtual
services
or
you
don't
allow
him
to
create
this
virtual
service.
A
A
So
to
do
that,
normally
you
need
to
create
like
a
lot
of
different
objects
like
your
virtual
service.
With
all
these
you
know,
parameters
like
a
destination
over
here
for
all
the
subset
that
you
define
in
the
virtual
service
a
service
entry
for
if
you
have
like
multi-cluster
rules
like
I
you
see
here,
I
want
to
target
another
cluster,
so
I
need
to
tell
istio
how
to
contact
the
service
on
this
cluster.
A
So
you
need
to
give
like
the
ip
of
the
steel,
ingress
gateway
and
the
port
and
so
on,
and
then
some
other
objects
you
create
on
the
other
cluster.
So,
as
you
can
imagine,
first
over
is
quite
complex
and
it
would
be
very
difficult
to
define
airbag
holes
for
that.
You
would
have
to
create
like
a
lot
of
holes
and
roll
bindings
on
both
clusters,
and
still
you
will
need
to
create
all
these
objects.
A
So
that's
where
glue
mesh
is
very
interested,
so
glue
mesh
you
deploy
it
either
in
one
of
the
cluster
or
even
in
a
third
cluster,
where
you
just
have
management
software
running
here
and
instead
of
having
to
define
all
these
complex
objects,
you
just
create
a
very
simple
abstractions
like
this
traffic
policy.
Here
you
see
very
simple
to
read.
A
When
I
have
a
request
going
to
the
review
service
on
cluster
one,
then
I
want
to
do
traffic
shifts
and
send
75
percent
in
the
other
cluster
on
version
3
and
then
15
percent
locally
on
version
1
and
10
percent
locally
on
version
2.,
so
first
benefit
of
blue
mesh.
It
allows
you
to
just
express
what
you
want
to
do
with
a
very
simple
policy
that
we
call
traffic
policy
and
then
it
creates
all
the
complex
objects
for
you
and
it
maintain
them.
So
it
makes
your
life
a
lot
easier.
A
A
A
First
of
all,
you
you
create
what
we
call
a
virtual
mesh
that
can
be
composed
of
multiple
clusters
where
istio
is
deployed,
and
then
you
enable
global
access
policy,
which
means
that
by
default
everything
is
forbidden.
So
no
services
can
talk
together
and
then
you
build
your
access
policies.
So
it's
another
abstraction.
We
discussed
about
the
traffic
policy
before
here.
It's
a
what
we
call
access
policy.
A
So
here
you
you
have
like
this
abstraction
where
you
can
say.
Okay,
this
service
account
on
this
cluster
can
send
requests
to
the
services
that
match
the
destination
selector
and
the
service
account
here
is
unique
between
clusters.
If
you
deploy
everything
correctly
and
you
have
different
trust
domains
and
so
on,
I
won't
go
through
the
details,
but
basically
these
policies
are
global
policies
and
that's
what's
really
important.
A
A
Create
a
lot
of
different
istio
objects
and
even
with
a
single
cluster
istio
deployment,
we
see
that
we
don't
get
the
the
granularity
we
we
need
so
again.
Another
thing
that's
coming
with
gloomesh
and
that
we
are
focusing
on
in
this
video
is
this
airbag
capability,
where
you'll
be
able
to
define
who
can
create
what
kind
of
policy?
So
this
user
can
create
a
traffic
policy,
but
only
that
way
this
user
can
create
an
access
policy,
but
only
that
way.
So
what
you
see
here?
A
First
of
all,
let's
take
a
look
at
our
environment,
so
we
have
this
nice
ui
that
comes
with
a
glue
mesh
enterprise
and
in
this
ui.
What
you
see
is
that
we
have
like
a
virtual
mesh
that
is
composed
of
two
service
mesh
clusters
that
you
see
here,
cluster
one
and
cluster.
Two,
where
I
have
istio
deployed
on
both
of
them,
and
you
can
see
we
automatically
detect
like
traffic
targets
and
and
workloads
that
are
running
there.
You
can
take
a
look
at
the
different
policies
you
see
here.
A
A
A
So
what
we
have
in
this
in
globe
in
in
gloomesh
in
term
of
airbag,
that
by
default,
we
have
this
admin
role,
and
you
see
it's
very
similar
to
in
terms
of
naming
to
the
kubuntu's
airbag.
You
have
roles
and
all
bindings,
but
you
see
the
the
api
version
here
is
different
and
you
see
we
have
a
lot
of
granularity
here.
So
we
can
say
this.
This
admin
can
do
everything.
A
You
see
a
lot
of
stars
everywhere,
a
lot
of
wild
cards,
but
that
gives
you
an
idea
about
the
the
granularity
you
can
define
what
kind
of
policy
can
create.
So
if
you
remove
these
access
policies
completely
here,
then
this
role
doesn't
allow
the
user
associated
to
the
role
to
create
any
access
policy.
A
A
You
see
like
the
the
the
weights
that
I
described
before
and
what's
interesting
as
well,
is
that
in
the
the
blue
mesh
ui
I
can
go
here
and
click
on
all
base
access,
and
I
can
see
this
admin
role
policy
as
as
I
described
before.
Basically
it
allows
everything
and
I
can
also
see
the
binding.
So
I
can
see
here
that
I
have
this
quest
admin
that,
as
this
admin
hold,
so
it's
very
nice
for
control,
making
sure
that
you
can
see
very
easily.
A
If
there
was
you
know
no
mistake
made,
you
know
someone
had
too
many
permissions
and
stuff
like
that.
So
that's
like
an
admin
role
now,
let's
say-
and
we
discussed
about
this
use
case,
which
is
very
very
common
like
I
want
to
have
like
a
namespace,
I
mean
I
want
to
segregate
my
cluster
with
namespaces.
A
A
So
I'm
going
to
apply
that
now
and
now
that
I
am
like
having
this
namespace
admin
role,
I
can
try
to
create
here
and
you
see
like
I
I
can.
I
am
an
admin
of
the
default
namespace.
I
don't
think
I
mentioned
that,
so
it's
it's
quite
important
and
here
as
an
admin
of
the
of
the
default
namespace,
I
want
to
create
a
traffic
policy
that
will
impact
the
traffic
on
the
ns1
namespace.
A
So
let's
try
to
do
that
and,
as
you
can
imagine
it's
not
a
lot.
So
that's
that's
really
what
I
I
wanted
to
to
get
at
the
end.
You
know
I
wanted
to
make
sure
that
I
am
not
you
know,
because
now
I
am
just
like
a
default
namespace
admin,
so
I
can
only
create
object
on
the
default
namespace.
Now
I
cannot
impact
the
other
namespaces.
A
Obviously
they're,
just
like
a
simple
example
and
with
the
granularity
that
you've
seen
when
we
create
these
different
roles,
you
can
do
much
more.
I
mean
you
could
have
use
cases
where
some
people
can
only
define
access
policies.
They
are
like
the
part
of
the
security
team
and,
and
they
focus
on
just
that
part.
You
know
the
access
policy
determining
determining
which
service
can
talk
to
which
service
some
other
people
could
perhaps
be
allowed
to
do
anything
they
want,
but
only
in
one
cluster
they
are
not
allowed
to
do
multi-cluster
things.
A
Perhaps
they
are
part
of
a
dev
team.
You
give
them
resources
in
the
local
cluster,
but
the
remote
cluster
is
only
like
for
production.
I
don't
know
like
that.
That's
another
use
case.
You
could
also
have
roles
where
you
only
allow
like
a
little
bit
like
the
namespace
I
mean,
but
basically
you
can
only
create
holes
that
impact
the
target
services,
not
the
source
services.