►
From YouTube: 014 Istio and Gloo Mesh Security Model
Description
In this talk, we dig deeply into Istio's security policies including Authentication/Authorizations and how it works under the covers with Envoy proxy.
A
A
A
So
let's
go
ahead
and
get
started
so
we'll
we'll
have
a
quick
intro
of
the
istio
security
model
in
general
and
kind
of
how
you
know
envoy
fits
into
all
of
that.
The
envoy
sidecar
proxy
fits
into
all
of
that
then
we'll
take
a
little
bit
of
a
closer
look
at
the
peer
authentication
features
in
istio.
Then
we'll
take
a
look
at
the
authorization
policies
that
are
available
to
you
in
istio
and
then
finally,
we'll
take
a
look
at
the
access
policies
that
are
available
to
you
as
a
glue
mesh
user.
A
So
to
get
started,
let's
take
a
look
at
istio
security,
so
so
this
diagram
comes
directly
from
the
istio
documentation.
This
is
a
high
level
overview
of
kind
of
the
istio
security
architecture.
So
down
at
the
bottom,
you
have
the
control
plane
and
the
control
plane,
you
know,
will
perform
various
features
from
a
user
or
operator
perspective.
A
This
is
where
you
apply
your
you're,
essentially
applying
your
policies
or
configuration
to
more
than
likely
your
kubernetes
api
server,
that's
stored
in
fcd
or
whatever
the
configuration
store
is
right
and
then
that
it's
translated
by
the
control
plane
and
sent
to
the
various
proxies
that
are
part
of
the
data
point
right
and
from
a
data
plane
perspective.
You
know,
as
a
user
when
you
make
a
request
or
when
you
have
service
to
service
communication,
the
actual
request
or
the
traffic
flows
through
these
sidecar
proxies
and
potentially
your
ingress
and
egress
gateways.
A
So
the
you
know
the
in
this
case,
where
we'll
look
at
the
service
and
service
b.
You
know
if
service
a
and
service
b
need
to
talk
to
each
other
they're,
not
going
to
communicate
directly
right
the
the
side,
cars
kind
of
mediate
that
communication
and
then
from
a
client
perspective
or
a
consumer
right
you're,
making
a
request
into
an
api
that
lives
in
the
service
mesh
right.
You
can
do
jot
enforcement
or
tls
or
even
mutual
tls
at
that
level,
right
and
that's
enforced
by
the
the
ingress
gateway.
A
If
you
know,
if
that's
in
the
in
the
data
path
right
and
then
from
the
ingross
gateway,
it
can
go
to
a
sidecar
proxy
of
service
a
and
that
will
happen
over
mutual
tls
and
then,
if
service
needs
to
service
b.
That
communication
also
will
go
through
the
sidecar
proxies
right
and
that
communication
will
also
happen
over
mutual
tls
for
the
mutual
tls
perspective.
You
know
in
order
for
that,
to
work
these
service
id
these
service
workloads
need
to
have
identity
right,
and
so
that's
one
of
the
other
features.
A
A
A
It's
plain
text,
so
no
https
right
it's
to
the
http
bin
service,
which
is
outlined
over
here
and
then
the
port
8000
is
the
destination
port
of
the
service
right,
so
so
kind
of
long
story
short
what
happens
when
the
sleep
pod
or
when
the
sleep
application
makes
this
request.
It's
actually
going
to
go
through
the
sidecar
proxy
on
the
client
side
right,
and
so
there
is
essentially
what's
called
a
listener
and
we'll
get
a
little
bit
deeper
into
this
there's
a
listener
in
the
envoy
sidecar.
A
That's
going
to
know
when
you're
making
a
request
or
trying
to
establish
a
connection
to
http
bin
right,
and
so
in
this
case
it
will
go
through
the
port,
8000
sidecar
right
and
then
from
here
the
request.
So
again,
this
communication,
this
connection-
was
established
over
plain
text.
Then
from
here
it's
going
to
go
over
istio
mutual
tls
to
the
inbound
or
the
you
know:
the
server
side,
the
workload
sidecar
proxy
right,
and
that
happens
because
these
envoy
proxies
can
speak
mutual
tls
essentially
to
each
other
right.
A
So
this
port
15006,
we'll
get
into
this
in
a
little
bit.
But
essentially
what
you
need
to
know
is
that
this
is
really
the
the
what's
called
a
virtual
inbound
listener
for
for
a
given
workload
and
so
we'll
we'll
kind
of
get
into
the
details
of
how
this
works.
But
you
know
this,
this
piece
is
what
receives
the
connection
from
the
sleep
application.
A
You
know,
then
the
proxy
is
going
to
do
whatever
processing
it
needs
to
do,
and
then
the
request
will
ultimately
make
it
to
the
http
bin
app
on
port
80,
because
that's
the
target
port
right.
So
we
don't
have
time
to
go
through
every
single
hop,
so
what
we're
going
to
do
is
we're
going
to
zoom
in
on
this
inbound
kind
of
request
to
envoy
and
take
a
look
at
how
that
actually
works.
A
A
So
what
ends
up
happening
when
you're
trying
to
request
a
service
in
kubernetes
and
depending
on
whether
or
not
you
were
using
a
sidecar
or
you're,
using
just
regular
kubernetes
networking
you
know
kind
of
depending
on
that,
will
determine
how
this
this
ip
address
gets
kind
of
used
as
the
destination,
but
we'll
just
look
at
the
the
kind
of
the
kubernetes
perspective
right.
So
you
have
a
kubernetes
service
which
really
you
know
the
the
backing.
A
Implementation
of
the
service
is
a
set
of
endpoints,
and
so
this
is
kind
of
an
example
of
the
endpoints
for
that
service,
where
in
this
case
we
only
have
one
of
them.
So
when
you
try
to
make
a
request
to
the
http,
then
service,
you
really
end
up
getting
sent.
You
know
to
this
ip
address,
there's
only
one
of
them,
so
you
get
this
10.1.1.9
and
then
remember.
A
The
target
port
was
80,
so
we're
going
to
go
to
this
ip
and
this
port
combination
in
order
to
get
a
unit
established
connection
to
the
service
that
we're
trying
to
contact-
and
so
that's
represented
over
here,
this
10.100.1.9
port
80.,
and
so
this
this
this
connection
is
trying
to
be
established.
Here
again.
This
is
also
mutual
tls
traffic
and
then
just
as
a
reminder,
kind
of
from
the
layer,
7
or
http
perspective.
This
is
what
that
request
looks
like
so
this
15006.
A
What
does
that
actually
mean?
So
when,
when
the
sidecar
starts
up
one
of
the
things,
that's
one
of
the
components
of
really
using
istio
is
that
you
inject
the
sidecar
but
there's
also
an
init
container
that
gets
injected
kind
of
as
like
the
standard,
the
kind
of
the
standard,
istio
installation
and
what
that
init
container
does
is.
It
runs
some
ip
tables
rules
that
essentially
will
hijack
the
any
packets.
A
Basically,
that
are
intended
for
certain
you
know
destinations,
and
so
in
this
case
you
know
kind
of
at
a
high
level,
all
incoming
connect,
all
incoming
packets
that
are
really
destined
for
this
application.
So
in
our
case
http
bin,
you
know
everything
that's
being
sent
to.
It
is
really
going
to
get
hijacked
and
it's
going
to
be
redirected
to
this
port
15006
and
so
from
a
listener's
perspective.
You
know
the
listener
is
what
the
envoy
component
that's
responsible
for
accepting
connections,
and
you
know
then
doing
something
with
that
connection
right.
A
So
this
is
the
listener
config
for
that
virtual
inbound
and
the
listener
is
listening
for
port
15006
and
it
does
so
on
all
ip
addresses,
but
the
15006
part
is
important
right
because
we're
redirecting
incoming
traffic
to
this
specific
port
and
so
we'll
we'll
we'll
take
a
look
at
you
know
what
actually
happens
to
you
know
because
we're
not
really
using
this
15006
port
right.
This
is
transparent
to
the
applications,
but
but
we
know
that
it's
being
redirected
to
it.
A
A
Listening,
that
incoming
connection,
it's
a
little
more
complicated
in
istio,
because
we
have
several
of
these.
So
really
you
have
you
know
there
there's
a
concept
of
multiple
filter
chains
and
in
order
to
determine
which
filter
chain
to
use,
there's
a
concept
of
a
filter
chain
match,
and
so
this
listener
config
over
here
kind
of
shows
an
example
of
that.
Where
you
have
a
we,
we
have
a
filter
chain
match,
so
we
have
one
set
of
filter
chains
and
in
order
to
determine
which
one
to
use
we
determine
we.
A
We
do
some
testing
of
you,
know
some
incoming
connection
properties
and
so
on
to
determine
whether
or
not
this
is
a
match
and
if
it's
a
match,
then
we'll
use
the
filter
chain
associated
with
this.
With
this
match,
and
so
in
this
case
we
do
have
a
match.
We
have
a
destination
port
of
80..
So
again,
remember
our
our
destination.
Port
is
80
right,
even
though
the
ip
tables
redirect
happened
and
so
on,
we
still
have
access
to
the
real
original
destination
which
in
this
case
was
80..
So
this
is
a
match
here.
A
The
transport
protocol
is
tls
because
remember
this
is
the
incoming
mutual
tls
connection
and
then,
finally,
this
application
protocol
section
this
is
necessary
because
istio
by
default
runs
in
something
called
permissive
mode
which
we'll
get
into
in
a
little
bit.
But
really
this
is
saying
that
you
know
I
am
speaking
istio
mutual
tls,
even
though
you
know,
potentially
there
are
other
people
that
are
speaking
tls,
so
so
it's
a
little.
A
A
So
we
know
that,
given
this
given
this
match
now,
we
know
that
we
can
use
this
set
of
filters
in
order
to
process
that
connection
before
we
actually
look
at
the
filters,
though
there's
another
component
to
this,
which
is
called
the
transport
socket
and
the
transport
socket
is
what's
responsible
for
actually
performing
the
the
tls
or
you
know
the
the
the
ssl
kind
of
the
ssl
or
tls
component
of
the
connection
right.
So
in
this
case,
this
transport
socket
config
also
is
defined
right
alongside
the
filters.
A
So
when
we
get
a
filter
chain
match,
we
know
that
we
need
to
use
the
transport
socket,
that's
defined
along
with
it
right,
and
so
the
the
the
tls
the
transport
socket
does
a
couple
of
things.
So
really
in
this
context,
what
we're
doing
is
we
have
this,
this
transport
socket
as
part
of
our
listener.
So
that's
saying:
okay,
we're
going
to
be
we're
essentially
saying
that
we
need
to
do
tls
on
this
incoming
connection.
But
more
importantly,
we
also
are
saying
that
we
require
this
client
certificate.
We're
setting
that
to
true.
A
So,
in
other
words,
this
is
mutual
tls
right.
So
not
only
are
we
going
to
do
tls,
but
we're
going
to
require
that
the
client
presented
a
certificate
and
then
we'll
actually
perform
mutual
tls
essentially,
and
then
what
we
also
are
providing
is
a
way
to
validate
that
client
certificate,
because
it's
not
enough
that
someone
provide
for
the
client
presents
a
certificate
right.
We
need
to
actually
validate
that.
A
The
way
that
we
determine
the
way
that
we
receive
the
configuration
of
the
root
ca
so,
like
you
know
the
public
cert
to
actually
perform
the
validation
happens
over
sds
and
that
so
so
that
it
can
be
done
dynamically.
Essentially,
okay,
so
we
covered
the
transport
socket
and
we
know
that
that's
associated
with
this
match
now
we
can
actually
get
to
the
filters
so
they're
kind
of
several
tiers
of
filter
kind
of
the
one
that's
called
out
here-
is
a
network
filter
right.
A
So
this
is
what
happened
this
this
network
filter
is
called
the
http
connection
manager
there
is
actually
more
to.
There
are
other
filters
that
are
part
of
it,
but
this
this
hcm
or
http
connection
manager
is
probably
the
most
important
for
for
explaining
what's
going
on,
so
that
this
hcm
is
responsible
for
actually
all
of
the
http
type
of
processing.
A
That's
that
happens
in
envoy,
and
so
you
know
associated
with
this
filter
chain
match
is
the
set
of
network
filters,
which
also
includes
this
hcm,
and
so
that
hcm
then
has
a
set
of
http
filters
associated
with
it,
and
so
you
kind
of
kind
of
looks
like
this
right.
So
we
have
the
connection
coming
in.
We
did
the
filter
chain
match,
so
we
determine
which
filter
chain
to
use.
We
also,
we
also
determine
which
tls
transport
socket
to
use.
A
A
Then
we
have
istio
stats,
which
you
know
provides
all
the
nice
statistics
that
you
can
get
with
istio
and
then
the
last
one
in
the
chain
is
the
router
and
the
router
is
what
the
the
filter
that
actually
handles.
You
know
sending
the
request
to
where
the
correct
destination,
where
it
actually
needs
to
go,
and
so,
given
all
of
that,
you
know
that's
kind
of
how
we
that's
kind
of
like
what
we'll
build
on
top
of,
because
all
of
the
security
features
we
already
touched
on
quite
a
bit
with
the
tls
transport
socket.
A
A
So
now,
let's
take
a
look
at
the
peer
authentication
resource,
so
at
a
high
level,
peer
authentication
is
really
what
you
know
what
happens
as
far
as
like
how
do
I
validate,
or
how
do
I
verify
who
the
client
that's
trying
to
make
a
connection
to
me
as
a
workload
right
so
from
you
know,
server
from
the
server
side
right.
If
someone
is
trying
to
establish
connection
with
me
and
in
order
to
send
a
request,
I
have
to
verify
who
that
is
right
and
that's
kind
of
the
whole
concept
of
peer
authentication.
A
This
this.
This
description
comes
directly
from
the
documentation
as
well,
but,
ultimately
right
peer
authentication.
Is
configuring
and
controlling
the
level
of
mutual
tls,
and
in
other
words,
you
know
how
you
cannot
know
or
how
you
can
identify?
Who
is
trying
to
establish
a
connection
with
you,
so
in
order
to
configure
that
there
is
a
custom
resource,
that's
called
the
peer
authentication
resource
and
here's
an
example,
and
really
you
know
what
you're
doing
is
you're
you're,
creating
this
pure
authentication
resource
in
order
and
applying
it
to
specific
workloads
by
default.
A
Istio
is
installed
in
permissive
mode.
We'll
we'll
take
a
look
at
that
here
in
a
second,
but
when
you
want
to
change
that
right,
you
can
target
it
by
creating
this
pure
authentication
resource
and
applying
it
to
your
mesh,
and
you
can
apply
it
at
different
levels.
So
you
can
apply
it.
You
know
mesh
wide
namespace
to
you
can
go
down
to
a
specific
namespace.
A
You
can
even
go
to
a
specific
workload
in
that
namespace
and
even
further
you
can
go
down
to
a
port
level
configuration
if
you
need
to
and
the
most
narrow
scope
takes
precedence.
So
this
is
important
because
you
know,
if
you
have
a
mesh
wide,
config
and
again
kind
of
the
default.
Config
is
permissive
you
can
have.
You
know
you
can
go
more
narrow
and
say:
okay,
I
want
to
do
this
one
namespace
to
strict.
While
I
leave
the
mesh
wide
config
at
permissive,
for
example,
so
again
permissive,
we've
kind
of
touched.
A
We
haven't
really
fully
defined
it.
We've
talked
about
it
a
little
bit.
Permissive
mode
means
that
workloads
can
accept
both
plain
text
and
mutual
tls
connections.
So
in
other
words,
you
know,
if
you
have
a
service
to
service
call,
you
know
and
that
that
service
service
call
can
is
two
workloads
that
have
sidecars
you're,
going
to
get
mutual
tls
even
in
permissive
mode,
and
that's
that's
really
cool
because
you
don't
have
to
you
know,
do
anything
essentially
to
get
mutual
tls
right.
A
If
you
have
side
cars
that
are,
if
you
have
workloads
that
have
side
cars,
communicating
with
each
other,
even
permissive
mode,
that
will
automatically
happen
over
mutual
tls,
but
that
also
means
that
legacy
clients
can
still
work
in
permissive
mode.
So
if
you
have
an
application
and
you
have
it
injected
with
a
sidecar,
a
client
that
doesn't
have
a
side
car
can
still
interact
with
the
with
the
workload
that
does
have
the
sidecar,
and
so
that's
that's
useful
from
an
introduction
perspective.
A
It's
useful
from
an
onboarding
perspective,
but
that
being
said,
it's
much
less
secure
right
because
you
cannot
validate
or
you
can't
verify
who's
actually
connecting
to
you
as
a
workload.
You
cannot
enforce
things
as
far
as
like
you
know.
I
only
want
specific
services
to
be
able
to
talk
to
me.
So
you
know,
permissive
is
great
and
permissive
is
important
as
far
as
like
migration,
like
you
know,
if
you're
on
board
into
your
service
mesh,
you
know
again,
it's
kind
of
you
know
we're
talking
about
a
journey
right.
A
A
A
So
again,
we've
been
talking
about
kind
of
scoping
right,
and
so
this
is
kind
of
like
what
it
looks
like.
So
when
you
you
can
have
a
mesh
wide
policy,
and
so
in
this
case
we
have
a
pure
authentication
resource
that
is
defined
in
the
istio
system,
namespace
and
in
this
case
there's
no
selector.
So
we'll
take
a
look
in
a
second.
What
that
looks
like
with
the
selector,
but
in
this
case
there
is
no
selector,
and
since
it's
defining
the
istio
system,
namespace
that's
kind
of
the
root
namespace
by
default.
A
A
Then
you
can
scope
it
down
one
level
further
and
go
to
the
name
space.
So
in
this
case
we
have
a
peer
authentication,
that's
strict,
but
we
don't
have
a
selector,
but
the
namespace
is
foo,
so
we're
not
actually
targeting
the
the
default
configuration
the
root
name,
space,
we're
targeting
a
you
know:
random
username,
space,
more
or
less.
A
Only
and
then,
finally,
you
can
go
one
level
deeper
and
you
can
you
know
so
in
this
case,
what
we're
doing
is
we're
disabling
mutual
tls
on
a
specific
port
of
the
http
bin
application
right,
and
this
is
useful,
if
you
have
kind
of
some,
you
know
legacy
application
that
has
certs
built
into
it
or
something
like
that
where
you
you
want
to
keep
that
functionality
in
place
and
you
don't
want
istio
mutual
tls
to
take
over.
You
know
this
is
a
useful
tool
for
that.
A
So
one
of
the
components
that
you
know
is
responsible
for
building
up
the
security
features
in
istio
is
the
issue
authentication
filter,
and
so
this
is
an
http
filter,
that's
built
into
like
it's
automatically
added
to
your
filter
chain.
So
remember
earlier
we
were
talking
about
the
filter
chain,
match
and
selecting
the
appropriate
filter
chain.
You
know
when
you,
when
you
have
istio
mutual
tls
enabled,
which
is
you
know,
pretty
much
always
when
you
do
that.
A
You'll
have
this
issue
authentication
filter
in
your
http
filter
chain,
and
so
in
this
case
right
where
we
have
it
outlined
here,
where
we
have
the
the
steel
off
and
filter
in
our
http
filters.
So,
as
a
request
comes
in
one
of
the
filters
that
will
process
it
at
the
http
level,
is
the
issue
authentication
filter,
and
so
what
this
this
is.
The
this
is
an
example
of
what
the
config
for
that
actual
filter
looks
like
the
config.
A
Isn't
too
interesting,
really
we're
just
saying
you
know,
there's
a
policy,
and
you
know
we
do
peers
by
mutual
tls,
more
or
less,
and
then
there's
also
the
skip
validate
trust
domain.
This
is
we're
not
going
to
go
too
into
this,
but
it's
just
called
out
here
for
completeness,
because
this
is
what
the
config
looks
like
if
you
were
to
look
at
the
config
for
your
istio
authentication
filter.
A
So
what
what
this
filter
itself
does
is
it
will
validate
that
the
connection
uses-
and
this
is
in
strict
mode-
it
will
validate
the
connection
using
mutual
tls
and
that
the
pure
or
in
other
words
the
client
certificate,
is
a
valid
spiffy,
cert
and
then,
more
importantly,
or
we,
I
don't
say
more
importantly,
but
one
of
the
other
important
things
that
it
does
is.
It
saves
the
pure
data
for
use
in
later
filters.
A
So
you
know,
with
this
filter
in
place
with
strict
mode
on
you'll,
get
the
the
validation
of
the
peer
cert
and
in
fact,
you
kind
of
get
that
for
free
already
with
the
transport
socket
config.
We
were
looking
at
earlier,
but
this
provides
another
layer
to
that
and
then
the
the
saving,
the
pure
data,
we'll
take
a
look
at
this
right
now.
A
A
The
namespace,
which
is
foo
and
the
service
account
that's
running
the
workload
that
made
the
request.
So
the
sleep
service
account
because
the
sleep
service
account
is
what's
running
the
sleep
application
and
then
you'll
see
that
we're
also
calling
out
that
we,
the
filter,
is
going
to
save
some
of
this
dynamic
metadata,
and
so
we'll
look
at
this
here
in
a
second.
What
that
actually
means.
But
you
see
that
the
source.namespace
is
foo
and
the
source.principle
is
this
cluster.local
namespace
foo
service
account
sleep.
A
So
what
happens
is
dynamic.
Metadata
is
an
envoy
concept
or
feature
that
more
or
less
allows
you
to
pass
data
from
the
various
filters
in
your
filter
chain,
and
in
this
case,
what
what
we're
doing
is
the
ist
authentication
filter
is
going
to
save
off
that
authentication
data
right.
So
the
source.principle
is
that
identity,
we're
talking
about
and
the
source.namespace
is
foo,
and
this
is
going
to
come
into
play
in
the
next
section
where
we
look
at
authorization
policies.
A
So
let's
go
ahead
and
take
a
look
at
the
authorization
policies,
so
more
or
less
authorization
policies
are
really
just
how
you
can
do
access
control
right
so
based
off
of
the
identity
either
either
from
the
the
source
workload.
So
you
know
the
service,
that's
calling
you
or
even
on
the
request.
You
could
do
authorization,
so
we
didn't
look
at
it,
but
you
can
also
do
things
like
based
off
the
jot.
That's
on
a
request:
let's
enforce
access,
control
on
the
identity
of
the
the
request
which
is
contained
in
the
chat.
A
For
example,
but
yeah,
so
authorization
policies
allow
you
to
do
access
control,
so
the
actual
the
authorization
policy
resource
is
what
controls
that
the?
What
you
really
get
here
is
like
this
is
so
you're.
Writing
your
access,
control
rules,
and
you
do
so
by
targeting
a
workload
which
is
what
the
selector
field
does.
A
So
the
authorization
policies
work
in
a
way.
That's
called
what
the
documentation
calls
out
as
implicit
enablement.
So
in
other
words,
you
don't
have
to
do
anything
to
start
using
them.
When
you
don't
have
any
authorization
policies
present.
You
know
everything
works
normally
right,
there's
no
access
control
going
on,
but
once
you
create
an
authorization
policy,
then
it
starts
working.
A
So
once
you
have
an
allow
policy
in
place,
everything
that's
not
explicitly
allowed
gets
denied
and
then
you
can
even
build
on
top
of
that
and
you
can
actually,
you
know,
create,
deny
rules
right.
So
if
you
have
a
deny
and
allow
rule
deny
rule
all
deny
rules
are
evaluated
first,
so
the
deny
rule
will
be
evaluated
first
and
then
the
allow
policy
will
all
of
the
allowed
policies
will
be
run
and
again
you
know
if
there's
anything,
that's
not
either
explicitly
denied
or
allowed.
A
So,
no
matter
what
no
matter,
if
you
have
any
allowed
policies
or
not,
everything
will
be
denied
by
default.
You
know
this
is
a
little
bit
of
a
commitment
right,
because
this
means
that
every
access
control
rule
has
to
be
explicitly
created
in
order
to
allow
traffic
to
happen
to
flow
from
the
you
know.
A
What
actually
needs
traffic
to
flow,
but
it
does
kind
of
give
you
that
fail
safe,
that
you
know
that
no
matter
what
happens
there
is
that
catch-all
rule
that
will
deny
everything
so
kind
of
going
back
to
what
we're
looking
at
authentication
policies.
Authorization
policies
can
kind
of
be
scoped
as
well.
So
this
is
an
example
of
the
not
deny
all
rule
in
this
case.
It's
in
the
default
root
name
space
with
no
selector.
A
A
That's
the
the
destination
of
traffic
essentially,
and
then
you
can
also
specifically
target
a
workload
only
right
so
in
this
case,
we're
targeting
by
ht
the
http
bin
app
through
label
selection
in
the
food
name,
space
yeah.
So
then,
how
is
this
actually
enforced
right?
What
actually
happens
to
do
the
access
control
deny
or
allow
right
what
actually
happens
as
far
as
the
enforcement?
A
And
so
that's
what
hap
the
the
way
this
is
implemented
is
the
envoy
rbac
filter,
and
so
this
is
kind
of
an
example
of
the
rbac
filter
configuration
that
gets
automatically
generated
based
off
of
the
rules
that
we
were
just
looking
at
right.
So
you
know
again,
this
is
in
the
filter
chain
right,
so
we
have
the
the
steel
authentication
filter
that
we
talked
about
and
then
now
we
have
the
r
back
filter
in
place,
and
so
this
is,
you
know
the
config.
What
what
well?
A
Let's
take
a
look
at
what
this
actually
does
so
remember
that
the
istio
authentication
filter
was
saving
off
the
authentication
data
or
result
of
the
authentication
to
dynamic
metadata
right.
So
going
back
to
what
we
had
the
source.principle
in
the
in
the
dynamic
metadata
associated
with
the
istio
authentication
filter.
Was
this
cluster.local
namespace
foo
service
account
sleep
then
this
rbac
rule
is
going
to
check.
You
know
the
principles
that
are
allowed
essentially.
A
Is
you
know
that
does
some
and
or
type
stuff
to
this
is
in
place
so
that
you
can
build
out?
You
know
kind
of
complex
rules
or
policies,
but
in
this
case
we
have
a
very
simple
one,
which
is
saying
that
you
know
we
need
it
to
be
sleep
in
order
to
be
allowed
right,
and
so
the
r
back
filter
is
then
going
to
check
that
in
the
istio
authentication
metadata,
the
source.principle
is
an
exact
match
with
that
sleep
workload
right.
A
So
this
the
trust
domain
is
clustered.local,
the
namespace
is
foo
and
the
service
account
is
sleep,
and
since
that
is
what's
present
in
the
dynamic
metadata
of
the
ist
authentication
filter,
the
rbac
filter
is
just
checking
that
right.
In
this
case,
it's
checking
that
it's
an
exact
match,
and
it
is
so
now
the
request
is
allowed,
and
so
that's
how
the
enforcement
of
the
rbac
or
sorry
of
the
authorization
policies
actually
takes
place
is
by
this
envoy,
our
back
filter.
A
So,
finally,
let's
take
a
look
at
access
policies
in
glue
mesh,
so
access
policies
and
glue
mesh
are
essentially
you
can
think
of
them
as
authorization
policies
really
you're
you're.
Writing
policies
that
that
say,
I
want
to
allow
traffic
or
you
know,
communication
from
a
source
workload
to
a
destination
workload,
and
that's
what
the
access
policy
is.
A
So
you
know
this
is
not
going
to
go
into
the
full
weeds
of
you
know
how
you
use
glue
mesh,
but
the
glue
mesh
has
a
component
of
a
virtual
mesh
and
that's
exactly
what
it
sounds
like
right.
It's
a
virtual
mesh
made
up
of
several
other
meshes,
and
this
is
that
global
access
policy
that
is
called
out
here
in
the
documentation.
So
it
looks
like
this
right.
Global
access
policy
is
enabled,
and
this
is
essentially
more
or
less
what
what
that
deny
all
rule
does.
A
A
So
this
is
what
this
is,
what
the
access
policy
resource
looks
like
and
so
again
you're
talking
about
sources
and
destinations
right.
So
you
know
this
is
kind
of
a
trend.
This
is
so
it
does
get
translated
back
to
authorization
policies
in
istio,
but
this
is
kind
of
a
higher
level
view
of
that
right.
A
This
is
the
the
target
of
the
policy
right,
the
destination
of
the
policy,
so
the
sleep
service
account
in
the
food
name
space
in
cluster.
One
is
allowed
to
talk
to
the
http
bin
application
in
the
food
name
space
right.
So
what
that
kind
of
looks
like
is
what
what
actually
happens
is
that
you
have
this
access
policy
that
we
just
created.
We
apply
it
to
the
management
plane.
The
glue
mesh
networking
component
specifically
is
what's
looking
for
it,
and
then
that
gets
translated
into
the
actual
authorization
policies
that
are
translated
from
the
access
policy.
A
So
kind
of
more
specifically
right
here
was
the
access
policy
we're
just
looking
at
where
we're
saying
sleep.
The
sleep
service
account
and
the
food
name
space
in
cluster.
One
can
talk
to
the
http
bin
app
in
the
phone
name,
space
right
that
access
policy
is
applied
to
our
glue
mesh
management
plane
and
then
the
glue
mesh
management
plane
is
responsible
for
creating
the
authorization
policy
that
corresponds
to
it.
So
in
this
case
we're
creating
an
authorization
policy
in
foo
the
food
name,
space
for
http
bin,
and
then
the
source
is
the
cluster
one.
A
This
is
this
is
kind
of
a
new
thing
right.
This
is
since
we
have
multi-cluster.
The
trust
domain
is
not
going
to
just
be
cluster.local,
because
you
have
several
of
those
right,
so
you
need
to
have
identity,
identity,
kind
of
extends
to
the
cluster
as
well,
and
so
in
this
case,
the
trust
domain
is
cluster,
one
right.
So
that's
what
that's
where
this
is
used,
and
then
it
builds
out
the
principle
how
you
how
we
already
have
looked
at
just
with
plain
istio
right,
so
the
namespace
is
foo
and
the
service
account
that
runs.
A
It
is
sleep,
so
this
is
kind
of
how
that
translation
occurs
so
kind
of
looking
at
it
from
a
higher
level
right.
We
have
two
clusters
in
our
virtual
mesh
right
and
we
have
a
management
plane
for
a
glue
mesh,
and
so,
as
a
user,
I'm
going
to
create
this
access
policy
that
we
were
just
looking
at
right.
So
I
apply
this
to
the
management
cluster
or
you
know.
A
So
this,
actually,
this
authorization
policy
that's
created
is
not
going
to
allow
sleep
in
cluster
two
to
make
a
request
to
say:
http
bin
in
cluster
two
right,
so
the
sleep
pod
or
the
sleep
workload
in
cluster
one
can
talk
to
http
bin
in
cluster
one
and
in
cluster
two,
and
so
that's
kind
of
intentional
right,
because
the
the
services
or
the
service
accounts
that
are
in
the
various
clusters
that,
like
I,
just
said
that
the
identity
inc
now
will
include
the
cluster.
So
now
you
can
create
complex
or
compose.
A
A
A
But
this
authorization
poly
is
only
relevant
in
cluster
one,
not
cluster,
two,
because
there's
no
there's
nothing
that
can
actually
access
it
in
cluster
two,
and
so
the
management
plan
is
responsible
for
kind
of
figuring
that
out
and
kind
of
building
out
the
authorization
policies
based
off
of
that.
So
you
can
kind
of
see
how
this
allows
you
to
compose.
You
know
very
complex
rules.
That
kind
of
express,
pretty
complex
security
requirements
because
you
are
operating
in
a
multi-cluster
world
right
and
so
with
that
we'll
kind
of
call
it
a
day.