►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
One of the challenges of developing and securing microservice-based applications in large teams is that services are often developed with different languages and frameworks. Service mesh overcomes these polyglot challenges by moving various aspects of microservice authentication and authorization to a common infrastructure layer.
This webinar will focus on the various architectural options available to developers for securing microservices both with and without a service mesh. Neeraj will cover how you can leverage a service mesh like Istio in tandem with CNCF projects like SPIFFE and Open Policy Agent to simplify how you secure your microservices.
A
All
right
we're
about
four
after
got
quite
a
few
attendees
on
today's
call.
It's
obvious!
Why
we're
talking
about
service
mesh
today?
Thank
you
all
for
coming.
Welcome
to
today's
webinar
simplifying
micro
services,
security
with
the
service
mesh
I'm,
Willie,
Calvo,
ciencia
ambassador
and
head
of
Technology
Strategy
at
SolarWinds
I'll
be
moderating
today's
webinar.
A
We
would
like
to
welcome
our
presenter
today.
Our
star
ani
Rajesh
Lavar,
is
the
engineering
lead
Aston
mesh
I
do
have
a
few
housecleaning
items
for
us
to
walk
through
just
an
advance,
but
me
Raj,
taking
it
away
note
that
you're
all
here
on
a
webinar
that
you're
all
muted
at
the
moment.
We
do
highly
encourage
your
questions.
Please
pop
those
into
the
Q&A
and
any
time
that
you
have
a
question
will
likely
take
a
break
or
two
during
new
Rajas
presentation
to
answer
your
questions.
A
B
Thanks
Lee,
hello,
everyone
I
am
neeraj
I'm.
The
engineering
lead
at
Aspen
mesh.
Thank
you
for
joining
in
on
this
webinar
about
simplifying
micro
services,
security
with
a
service
mesh
before
I
begin.
I
would
like
to
give
a
quick
overview
of
how
my
presentation
is
structured.
So
it's
easy
to
follow
along
first
I'm,
going
to
talk
about
why
security
is
difficult
in
micro
services
as
compared
to
monoliths
and
then
move
on
to
some
of
the
key
concepts
of
micro
services,
security,
authentication
and
authorization.
B
Then
talk
about
how
servus
mesh
can
help
you
simplify
it,
especially
taking
Steve
as
an
example.
Talk
about
excuse
architecture,
then
zoom
back
in
into
the
key
concepts.
Around
authentication
and
authorization
take
various
architectural
choices
you
have
both
without
the
service
mesh
and
with
the
service
mesh
and
then,
like
I
likely
said
in
the
end,
we'll
have
some
time
for
Q&A.
So
with
that,
let's
get
started.
B
So
security
health
in
general
has
always
been
difficult.
It's
even
more
difficult
in
microservices,
as
this
illustration
represents,
we
are
no
longer
in
the
mono
line
or
the
monolith
world
as
compared
to
micro-services
when
I
think
about
micro
services.
There
are
three
key
things
which
are
different
that
make
the
security
even
harder
to
implement.
First,
there
is
no
single
point
of
control,
so
in
the
monolith
world
you
had
a
single
point
of
control
where
you
could
easily
protect
your
parameter.
B
If
you
were
protecting
your
ingress
using
a
big
IP
or
a
firewall
or
nginx,
you
were
secured
the
when
the
request
came
to
your
monolith.
Now
it
was
contained
within
that
monolith
and
more
or
less
you
were
using
process
level,
interface,
2
or
libraries
to
communicate
with
each
other.
Now
you
have
broken
apart
your
monolith,
and
now
you
have
multiple
micro
services,
and
these
micro
services
are
talking
to
each
other
over
network.
B
They
are
using
mirrors
of
protocols
and,
like
HTTP
gr
peace,
the
Redis,
so
you
have
just
increased
that
complexity,
and
you
have
lost
your
strategic
point
of
control
as
a
security
person.
You
can
see
how
this
can
be
very
difficult
to
manage.
Moving
on,
most
of
the
micro
services
are
built
using
polyglot
polyglot
languages.
What
I
mean
by
that
is
micro
services,
encourage
developers
to
write
applications
using
languages
that
make
it
more
efficient
and
that
make
it
more
easy
to
maintain.
Naturally,
that
means
you
will
have
applications
running
Java
go
no
js'
Python.
B
Now,
if
you're
trying
to
implement
security
using
libraries
or
using
these
frameworks,
you
can
imagine
the
complexity
as
these
languages
keep
on
growing,
because
you
are
embedding
your
security
in
the
applications.
First,
how
are
you
going
to
ensure
uniformity
across
these
languages?
It's
no
longer
a
single
languages.
It's
no
longer
a
single
language
that
you
can
just
implement
a
library
and
share
a
cross.
Additionally,
if
you
have
a
Quixote
patch,
no,
you
have
to
wait
for
that
patch
to
be
applied
on
all
these
frameworks.
B
Traditionally,
developers
and
operators
all
and
the
security
operators
always
have
a
strenuous
relationship.
It's
luck.
It's
kind
of
a
love
and
hate
where
they
both
need
each
other,
but
at
the
same
point
they
hate
each
other
because
they
might
slow
it
that
they
might
slow
their
progress
having
polyglot
applications
and
micro
sources
just
makes
the
relationship
worse.
The
security
people
are
more
coupled
to
the
developers
if
the
application
developer
is
responsible
for
enforcing
security.
B
Moving
on.
The
third
point
is
the
increased
surface
area,
which
in
a
way,
is
a
combination
of
the
first
two
points,
but
I
like
to
mention
it
separately,
because
it's
beyond
those
two
points
when
you
break
apart
a
monolith
into
microservices.
Yes,
you
are
increasing
your
surface
area
by
the
network,
calls
they
are
making
for
the
different
languages
they
are
using.
At
the
same
time
now
you
are
using
different
containers.
Those
containers
come
from
different
base
images
which
are
all
not
in
your
control.
B
Additionally,
you
might
be
deploying
your
containers
and
applications
and
environments
where
you
might
not
be
even
controlling
the
nodes
on
which
they
are
running.
So
all
in
all,
this
makes
enforcing
security
in
micro
services
a
lot
more
challenging
than
what
it
used
to
be
in
monoliths,
and
that's
why
it's
really
important
to
understand?
How
can
you
simplify
your
security
landscape
if
you
have
our
micro
service
architecture?
B
So
when
we
talk
about
key
aspects
of
Microsoft
security,
I
wanna
focus
on
two
key
things
here,
which
are
authentication
and
authorization
authentication
is
the
act
of
verifying
or
validating
your
end-user
or
the
client
who
is
currently
making
a
request
in
micro-services?
Sometimes
it's
actually
the
combination
of
both
because
the
client
which
is
connecting
to
you
might
be
a
micro
service
in
your
network,
but
it
might
be
making
a
request
on
behalf
of
an
end-user
request
that
kml.
So
it's
it's
crucial
to
understand
the
complication
that
arises
in
the
micro
service
world
just
for
authentication.
B
Normally,
you
will
authenticate
by
creating
a
login
and
a
password
most
of
the
modern
applications,
delegate
that
to
identity
management
solution
like
kognito,
where
the
login
password
goes
to
kognito.
The
AWS
company
no
framework,
for
example,
and
the
cognitive
framework
gives
back
a
chart
token
or
a
JSON
web
token,
where
the
applications
are
eventually
presented
that
token
from
the
end
user
and
that
token
acts
as
the
identity
as
the
request
moves
along
in
the
cluster.
The
token
is
the
identity
which
verifies
the
user.
B
It's
similar
to
saying,
if
you
have
different
roles,
for
example,
you
have
admins
readers
and
writers,
then
you
want
to
know
what
actions
they
can
or
cannot
do.
So.
With
that
background,
our
make
a
statement
here
saying
service
mesh
can
simplify
your
security
at
this
point.
This
is
just
the
statement,
hopefully
by
the
end
of
the
presentation.
I
have
convinced
you
that
this
is
the
truth
in
lack
of
service
mesh.
What
you
end
up
doing
is
to
just
to
enforce
authentication
and
authorization.
B
You
will
write
the
logic
in
your
applications,
making
them
too
complicated
and
coupling
your
operations
and
your
developers
team
to
too
close
and
too
tightly
service
measures
can
simplify
security
and
by
simplifying
what
I
mean
is
it
gives
developers
an
opportunity
to
offload
some
of
the
functionality
into
the
mesh.
So
let
me
give
a
quick
background
of
what
service
meshes
are
so
service
mesh
is
an
infrastructure
layer
that
handles
communication
between
your
micro
services
as
part
of
handling
the
communication
between
the
micro
services.
B
B
These
proxies,
which
are
not
just
parsing
at
layer
4,
but
they
are
passing
the
application
level
protocols.
They
can
implement
the
complex
functionality
of
authentication
or
authorization
as
they
understand
this
protocols
much
better
depending
on
where
and
how
you
place
your
proxy.
There
are
various
architecture
options
that
are
available
to
you
and
each
of
these
options
have
both
have
benefits
and
disadvantages.
B
One
of
the
architectural
options
is
a
sidecar
proxy
deployment,
and
this
is
what
the
service
mesh,
which
I
am
going
to
use
STO
uses
by
a
sidecar
deployment
model.
I.
What
I
mean
is
the
Envoy
proxy?
The
proxy
which
is
used
in
sto,
is
placed
in
the
same
pod
as
your
application
container
is
running
so
in
kubernetes.
If
you,
if
you're
using
kubernetes,
you
have
the
concept
of
pods,
where
you
can
have
multiple
containers
in
sto,
the
sidecut
proxy
will
be
placed
inside
the
same
pod,
which
means
from
outside.
B
They
look
like
the
same
Network
entity.
They
share
the
same
networking.
Namespace
and
the
IP
inside
they're
still
two
separate
containers,
so
they
have
separate
file
system
and
process
level
isolation,
so
this
gives
them
the
right
kind
of
isolation
that
you
want
and
uniformity
for.
The
network
where
you
can
have
the
application
container,
built
and
deployed
separately
and
thus
proxy
have
its
own
build
lifecycle.
B
So
normally
in
history
of
what
that
means
is
when
the
application
makes
a
request
out,
it
will
be
intercepted
by
the
sidecars
here
shown
in
pink.
Then
the
sidecar
is
eventually
going
to
make
a
request
out
to
the
other
container
in
which
the
request
will
again
be
intercepted
by
the
sidecar
container
and
then
eventually
forward
forwarded
on
to
the
application.
The
same
path
is
going
to
be
followed
for
the
reverse
side,
when
the
response
is
made
all
the
side,
cars
together
or
what
we
call
the
data
plane
of
the
of
the
steo
architecture.
B
History
has
a
nice
separation
between
the
control
plane
and
the
data
plane.
The
control
plane
here
is
shown
in
blue
at
the
top.
The
control
plane
is
responsible
for
configuring,
configuring,
the
Envoy
and
the
data
plane
proxies.
At
the
same
time,
it
is
responsible
for
providing
an
abstraction
layer
from
the
data
plane.
The
control
plane
itself
in
Sto
is
distributed,
so
the
control
plane
has
various
components
which
can
independently
scale,
and
you
can
upgrade
them
depending
on
the
requirement.
B
Similarly,
having
a
decoupling
between
the
control
plane
and
the
data
plane
gives
you
the
ability
to
independently
scale
and
upgrade
them
so
I'm
going
to
quickly
go
over
some
of
the
key
control
plane
elements
here,
so
that
we
can
use
them
later
in
representation.
So
first
is
pilot.
Pilots
job
is
to
provide
an
abstraction
layer
for
the
configuration.
So
it
looks
at
your
platform,
specific
configuration,
so
if
you're
using
kubernetes,
it
will
look
at
services,
endpoints,
pods
and
then
lower
it
to
the
configuration
that
envoy
understands.
B
Similarly
pilot
also
consumes
all
the
ICU
level
configuration
and
lowers
it
to
envoy.
This
provides
the
benefit
to
the
operators
where
they
can
use
their
platform,
specific
configuration
and
api's,
and
don't
have
to
worry
about
on
why
api's
second
is
mixer.
Mixer
provides
two
key
functionalities.
One
is
mixer,
provides
one
form
of
policy
enforcement.
We
will
talk
in
detail
later.
How
that
works?
The
second
is,
it
provides
a
layer
for
telemetry
abstraction
where
your
side
cards
or
the
data
plane
can
export
statistics
and
tracing,
for
example,
in
some
format.
B
But
mixer
can
transpose
this
and
add
as
a
adapter
layer
where
you
can
you
can
actually
anyway,
you
can
eventually
send
that
data
to
a
back-end
system
like
Prometheus
or
a
Google
stripe
driver.
So
in
this
way
again,
there
is
an
abstraction
between
what
the
data
plane
can
do
and
what
the
control
in
supports.
B
Citadel
is
the
control
plane
element
responsible
for
creating
certificates
and
rotating
certificates
on
a
regular
cadence.
So
in
Sto,
if
you
are
using
functionality
like
which
will
TLS,
which
I
am
going
to
cover
in
details,
l
is
the
component.
You
create
these
certificates
and
present
them
to
the
Envoy
sidecar.
Traditionally,
Citadel
always
use
the
platform
specific
mechanism,
so
it
will
use
things
like
kubernetes
secrets
and
those
secrets
will
be
mounted
on
the
filesystem
but
going
with,
but
from
sto
1.1
release
going
forward.
B
Citadel
provides
a
implementation
for
the
secret
discovery
service
or
the
SDS
API,
which
now
on
voice,
can
consume
directly
to
get
those
secrets,
and
this
makes
it
more
secure
so
that
the
secrets
or
your
certificates
and
keys
are
never
exposed
in
the
file
system
we
reducing
yet
rather
vector
of
attack.
The
sidecar
injectors
are
a
kubernetes,
specific
control,
plane
element
which
are
responsible
for
injecting
the
sidecars
automatically
when
the
file
when
the
pods
are
coming
up.
B
This
makes
sure
that
you
don't
have
security
escapes
if
you
are
relying
on
sto
for
enforcing
them,
where
some
ports
may
or
may
not
have
sidecars
the
last
two
components
are
the
ingress
gateway
and
the
egress
gateway.
The
ingress
gateways
responsible
for
letting
traffic
into
your
mesh
and
the
egress
gateway
can
be
used
for
controlling
traffic
out
of
your
mesh.
B
A
Those
burning
questions
see
your
Q&A
panel
below
ask
your
questions.
Also,
we
may
have
a
poll
for
you,
so
if
you
see
a
full
pop
up
be
on
the
lookout
for
that
we're
curious
as
where
people
are
on
their
journeys
with
with
service
master.
So
with
that
they
go
back
to
you,
Niraj
more
on
authentication,
all.
A
B
B
B
Absolutely
so
Citadel
is
responsible
for
creating
certificates
for
the
data
plane
or
the
Envoy
proxy
when
you
have
mutual
TLS
enabled
so
normally,
when
you
have
M
TLS
enabled
you
have
to
manage
certificates
for
both
the
client
and
the
server
side.
Normally
this
is
quite
painful
to
do
on
your
own.
You
have
to
keep
rotating
them,
so
Citadel
will
create
those
certificates
with
the
identity.
Is
that
I
am
going
to
talk
about
later?
B
Additionally,
Citadel
is
now
exposing
a
secret
discovery
service
API,
which
is
a
new
API
that
Anwar
added,
which
allows
you
to
fetch
those
certificates
and
secrets
directly.
So
you
don't
have
to
mount
those
certificates
on
the
file
system
and
because
you
are
no
longer
mounting
them
in
your
file
system.
You
are
reducing
your
vector
for
tax.
B
Right
thanks
Lee.
Let
me
continue
on
to
authentication
and
we
will
elaborate
we're
going
to
talk
more
about
Citadel
as
we
go
as
we'll
go
along
all
right.
So,
as
I
was
saying,
I
am
going
to
assume
that
you
are
using
some
sort
of
token
in
this
case
I'm
going
to
assume
you're
using
JWT
tokens
in
your
applications
to
validate
the
end
user.
So
this
is
the
first
option
you
can
do.
You
can
have
in
your
applications
where
the
application
itself
is
validating
the
chart
token.
So
here
we
have
two
applications
or
two
micro
services.
B
I
should
say
you
have
user
service
written
in
go
and
you
have
your
payment
service
written
in
Python.
So
the
end
user
is
making
a
request
which
comes
to
your
ingress
and
that
request
is
encrypted
and
it
has
a
JSON
web
token
in
it
as
the
authorization
header,
the
ingress
will
do
the
termination
for
those
requests.
So
that
means
normally.
This
is
the
format
I
have
seen,
which
many
users
and
many
organizations
have
ingress.
Is
the
TLS
termination
point
so
going
forward?
B
What
that
means
is
ingress
is
then
going
to
forward
those
requests
to
the
services
based
on
paths,
for
example.
So
here
if
it
is
a
slash
user,
it
goes
to
a
user
service.
If
it
is
slash,
payments
goes
to
the
payment
service.
So
what
that
means
is
the
request
which
contains
the
jar
token
in
authorization.
Header
is
passed
in
plain
text
from
ingress
to
the
backend,
and
then
the
backend
uses
some
sort
of
library
to
validate
the
jar
token.
And
then,
if
the
request
is
valid,
it
actually
processes
it.
B
If
it
is
invalid
that
it
sends
authentication
rejected
response
to
the
client,
so
there
are
two
problems
that
happens.
If
you
implement
this
architecture,
first
is,
as
you
can
see,
the
link
between
the
ingress
and
the
back
end
is
unencrypted.
That
means
you
are
opening
yourself
to
replay
attacks,
as
anyone
who
is
eavesdropping
on
the
network
can
capture
the
jar
token
and
assume
the
identity
of
the
end
user.
Second,
you
are
using
location
code
to
implement
this
validation.
B
That
means
you
will
have
to
periodically
fetch
or
at
a
startup
fetch
the
jargon
fetch
the
public
key
from
your
identity
management
solution.
At
the
same
time,
if
you
have
to
swap
out
the
identity
management
solution,
you
have
to
change
all
the
libraries
which
act
like
I
was
saying,
makes
the
coupling
between
the
security
team
and
the
developers
really
close
together.
So
that's
the
first
option.
B
Less-Than-Ideal,
let's
move
on
the
second
option,
which
is
also
I,
have
seen
many
companies
implement,
which
is
I,
am
going
to
move
my
logic
of
validating
chart
of
my
application
to
the
ingress
layer.
So
in
this
case
what
happens
is
the
ingress
is
responsible
for
communicating
with
the
aisle
to
management
solution
and
then
only
passing
a
law,
the
authenticated
request
of
the
backend,
so
you
have
done
one
thing:
you
have
offloaded
some
of
the
functionality
to
your
infrastructure,
that's
good,
but
at
the
same
time
you
still
have
two
outstanding
issues.
B
First,
is
the
request
that
comes
from
the
ingress
to
the
backend,
still
coming
in
plain
text,
so
that
means
you're
still
open
to
replay
attacks.
Second,
in
most
of
the
micro
service
architectures
that
I
have
seen,
you
will
have
a
nested
flow
of
calls,
so
the
payment
service
is
going
to
call
another
service
like
banking
and,
most
of
the
time
you
will
be
doing
a
propagation
of
the
identity,
so
you
will
propagate
the
chart
from
payments
to
banking.
B
But
again
you
don't
have
any
encryption
between
services
in
your
cluster,
so
you've
exposed
or
increase
the
surface
area
for
replay
attacks.
Every
hop
where
you
are
propagating
your
chart.
You
are
potentially
opening
yourself
to
some
security
vulnerabilities,
so
two
options
less-than-ideal.
So,
let's
see
what
sto
can
do
and
how
is
tio
can
simplify
this
for
you.
So
these
are
the
next
two
options
that
I'm
presenting
first
is
in
sto.
B
You
can
have
you
have
the
capability
of
configuring,
your
side,
car
or
your
ingress,
to
do
jar,
validation,
so
by
configuration
you
can
say
which
side
car
are
service
for
which
the
sidecar
is
attached.
You
can
do
chart
validation
at
that
point.
Additionally,
in
history,
you
can
configure
the
functionality.
You
want
your
English
to
do
so.
In
this
architecture,
we
will
say
we'll
configure
our
ingress
to
do
TLS
pass-through.
So
in
this
case
the
traffic
comes
encrypted
to
the
ingress
ingress,
we'll
do
sni
or
server
name
indication
based
routing.
B
So
if
you
look
at
the
host,
which
is
presented
in
TLS
during
the
TLS
negotiation
and
use
that
host
to
do
the
routing
so
instead
of
using,
if
you
see
slash
users
and
slash
payments,
now
you
have
to
do
domain
based
routing,
then
those
requests
are
eventually
given
to
the
side
cars.
The
side
cars
are
configured
to
do,
chart
validation.
B
So
what
that
means
is,
in
this
case
pilot
gets
your
configuration
from
the
operators,
so
that
configuration
has
things
like
charge,
URL
and
various
other
job
attributes
it
fetches
the
public
key
from
the
identity
management
system
and
it
configures
the
side
curves.
With
that
public
key.
When
the
side
car
receives
the
request,
it
uses
that
public
key
to
validate
the
chart.
Token,
if
the
token
is
valid,
if
the
signature
is
valid,
it
will
forward
forward
the
entire
token
to
the
backend.
If
it,
if
the
token
is
not
valid,
the
request
is
rejected.
B
So
this
has
two
benefits.
First,
is
the
back-end
only
receives
the
token
when
the
chart
is
actually
valid,
or
it
only
receives
the
request?
I
should
say
when
the
token
is
valid.
Secondly,
you
have
encryption
from
ingress
to
your
back-end,
but
it
also
has
some
downsides,
particularly
because
you
are
using
domain
based
routing
you
use.
You
lose
some
of
the
advanced
capability
peers
around
path
based
routing,
so
you
have
restricted
what
the
ingress
can
do.
B
Secondly,
because
still
you
are
not
attaching
identities
to
each
micro
service
when
the
sidecar,
when
the
application
is
trying
to
propagate
the
chart
headers.
So
in
this
case
when
payments
is
trying
to
talk
to
the
bank
service,
still
you
don't
have
encryption
in
that
link
and
you
are
still
exposing
yourself
to
replay
attacks.
Note
that
one
thing
is
important
here
where
the
sto
sidecars
by
default
will
only
propagate
job
headers,
one
hop.
B
B
So
Stu
has
the
capability
of
issuing
identities
to
every
service
in
your
cluster,
and
those
identities
will
be
unique
to
each
service.
Using
these
cryptographic
identities,
you
can
secure
traffic
at
each
hop.
So
in
this
example,
what
that
will
mean
is
the
users
traffic
is
presented
to
the
ingress
encrypted
the
ingress
or
the
sto
ingress
will
terminate
that
traffic.
Then
the
ingress
will
re-encrypt
the
traffic
with
mutual
TLS,
with
its
own
identity
and
the
identity
of
the
sidecar
for
the
user
service
or
the
identity
of
the
sidecar
for
the
payment
service.
B
So
you
have
encrypted
traffic
on
these
links.
Then
you
can
configure
the
sidecars
to
do
chart
validation.
So
in
this
case
you
will
say,
user
service
and
the
payment
service
will
do
chart
validation
and
then,
if
the
payment
service
wants
to
communicate
to
the
banking
service,
it
can
propagate
the
chart,
but
because
you
have
MPLS
between
those
links,
you're
never
leaking
your
jar
token
in
open.
B
This
is
a
drastic
improvement
as
compared
to
any
other
solution
that
we
have
told
them
before,
because
every
other
solution
had
holes
where
somewhere
or
the
other,
you
were
leaking
your
jar
additionally,
in
this
case,
citadel
like
I
was
explaining
before
is
responsible
for
creating
those
certificates
which
will
be
used
for
MPLS
and
automatically
rotating
them.
So
not
only
are
you
delegating
your
chart,
validation
but
you're,
also
getting
empty
LS
without
the
overhead
of
managing
certificates
for
you.
B
So
next
I
have
a
simple
example
of
how
you
can
actually
do
this
in
Sto.
So
if
you
want
to
configure
stom
TLS
plus
chart
here
are
the
things
that
you
need
to
configure.
First,
you
will
need
to
configure
mesh
policy
so
here,
as
it
says,
this
is
a
default
mesh
policy
which
is
turning
on
M
TLS
for
the
entire
cluster.
So
note
note
that
when
you
create
mesh
policy
or
authentication
policies,
you
are
only
configuring
the
server
side
for
controlling
M
TLS.
You
need
to
configure
both
the
server
and
the
client
sides.
B
The
client
side
configuration
is
done
by
configuring,
what
we
call
destination.
So
this
is
a
default
destination
rule
which
says
for
any
host
ending
in
star
dot
local.
So
that
means
for
any
host
or
services
that
you
are
communicating
to
within
your
cluster
within
your
kubernetes
cluster,
you
always
use
Istria
mutual.
So
this
is
one
area
where
I've
often
found
the
first-time
users
in
sto
tripping
tripping
over,
because
they're
confuse
as
I
have
enabled
empty
LS
policy
by
mesh
policy,
but
doesn't
work
so
you
need
both
the
sides.
B
Secondly,
when
you
want
to
add
chart
for
specific
services
so
for
this
example,
if
I
wanted
to
add
chart
for
HTTP
bin
service,
this
is
how
I
would
do
it.
I
will
create
the
authentication
policy
which
will
target
a
name
that's
to
be
built.
This
is
the
name
of
the
kubernetes
service
and
it
is
important
that
you
can
only
use
short
names
over
here.
Steve
will
automatically
create
fully
qualified
domain
names
based
on
the
namespace.
You
are
creating
this
racecourse,
so
there
are
two
important
things
to
note.
B
First,
you
are
creating
a
chart
section
here
which
will
say:
what's
the
issuer.
You
can
also
say
what
is
the
URI
from
where
you
want
to
fetch
your
public
keys.
Secondly,
it
is
very
important
to
always
specify
MPLS
here,
so
any
policy
that
you
write
will
always
override
the
default
policy.
So
in
this
case,
if
you
skip
specifying
MPLS,
what
will
happen?
Is
the
server
side
will
be
configured
to
just
use
chart
but
in
the
client
side
will
be
using
MPLS?
B
So
hopefully
this
example
helps
you
in
understanding.
What
are
the
pieces
you
need
if
you
have
both
MPLS
and
jack,
enabled
and
offloaded
to
a
steel?
So
next
I
want
to
show
how
the
policies
or
the
configurations
are
actually
lowered
from
hto
specific
configuration
to
envoy.
So
for
most
of
the
cases,
you
don't
care
for
this
if
everything
is
working
correctly,
but
for
debugging.
This
is
really
helpful
to
understand.
How
is
the
config
eventually
given
to
envoy
and
what
actions
does
envoy
take?
B
So
if
you
have
configured
jart,
as
you
can
see,
pilot
will
automatically
go
and
fetch
the
public
key
and
set
the
charge
filter
for
envoy
saying
either
the
keys
you
should--you
for
in
line
validation
and
then
forward
the
request
to
the
application
container.
It
is
also
configured
to
use
MPLS
on
the
server
side,
as
you
can
see,
and
then
there
are
a
few
things
like.
What's
the
principle
binding,
those
are
used
mostly
for
some
sort
of
attribute,
matching
and
generation.
B
B
So
this
is
what
we
call
s
wid
or
a
spiffy
verifiable
identification
document,
so
Citadel
automatically
creates
these
certificates,
which
have
a
subject
alternate
name
with
this
spiffy
spec
and
the
sidecars
are
configured
by
pilot
to
verify
that
the
sand
presented
from
the
other
side
honors
or
meets
this
criteria.
So
for
this
example,
whenever
one
who
is
trying
to
reach
out
to
this
cluster
HD
bib
in
dot
foo,
it
will
use
this.
B
It
will
verify
that
the
subject
name
matches
this
criteria,
and
this
spiffy
specification
is
built
around
the
domain,
which
is
curses
out
local,
then
the
namespace
and
then
the
service
account
that
is
attached
to
the
workload.
So
these
are
some
of
the
examples
of
how
you
can
use
Sto
to
offload
authentication
and
then
look
at
your
own
work
configuration
if
you
want
to
verify
that.
Actually
you
are
doing
what
your
support
you
have
configured
so
with
that
I'm
gonna
ask
Li.
A
B
Great,
that's
a
great
question,
so
the
first
thing
that
I
found
is
authentication.
So
if
you
just
want
a
tenth
occasion
to
be
done
by
the
sidecars,
you
can
do
so
in
which
case
when,
if
the
request
is
correctly
authenticated,
the
service
will
get
the
request
and
the
service
can
do
the
authorization
by
itself.
B
The
next
section
that
I'm
gonna
cover
explains
how
you
can
offload
the
authorization
functionality
also
to
the
match,
but
sto
by
default
is
always
additive
and
incremental.
So
if
you
have
built
some
of
the
logic
in
your
application,
you
don't
have
to
remove
it.
You
can
add
this
to
you
and
gain
some
functionality
and
then
eventually
move
things
out
of
your
application.
If
you
want.
B
A
B
So
maybe
this
is
a
clarification
in
terminologies.
So
whenever
we're
talking
about
service
service
itself
is
an
abstract
concept
in
kubernetes.
Eventually
it's
the
pod,
which
are
communicating
to
each
other,
so
traffic
between
pods
will
become,
will
be
by
default
encrypted
when
I
say
service
to
service
encryption.
Now
the
traffic
between
the
application
container
and
the
sidecar
container
is
mostly
in
plain
text,
but
that's
a
different
story.
A
B
Sounds
good
ly
all
right,
so,
let's
move
on
to
authorization
so
like
I
was
saying,
authorization
is
verifying
whether
the
user
or
the
client
who
is
connected
to
you
is
allowed
to
do
certain
actions.
So
normally
you
do
this
by
either
having
a
roll
Association
where
rolls
are
type
2
actions
and
then
a
user
comes
in
and
they
can
assume
a
role
or
they're
part
of
a
group
like
admin,
reader
or
writer.
This,
which
is
called,
are
bad,
there's
a
second
form
of
access
control,
which
is
attribute
based
access,
control,
I.
B
Think
of
this
as
a
little
more
complex
but
more
flexible
access
control
mechanism,
where
you
have
policy
framework
in
a
policy
language
set
up
and
you
have
set
of
attributes,
those
attributes
can
be
tied
to
resources.
The
users
are
anything
else
and
then
you
are
doing
complex,
boolean
or
thematic
kind
of
a
thing
to
determine
if
a
particular
user
request
is
allowed
to
go
through
or
not
for
most
of
the
cases
are
back
works
well,
and
it
is
good
enough,
but
in
certain
cases
you
might
need
a
back.
B
B
So
this
is
how
is
to
our
back
works,
so
the
the
or
the
operator
will
configure
is
to
your
policies,
pilot
watches,
for
them
from
the
kubernetes
api
server
and
distributes
the
appropriate,
our
back
and
our
back
artistics
or
the
our
back
rules
to
side
part
which
enforces
them
sto
by
default,
we'll
do
two
kinds
of
authorization:
one
is
service
to
service
and
the
second
one
is
end-user
to
service.
Just
like
authentication,
it's
important
in
micro
services
to
do
both.
B
You
can
have
one
service
talking
to
another
service,
then
you
want
to
know
what
it
can
or
cannot
do.
Additionally,
you
have
the
end
user,
who
is
making
requests,
and
then
you
want
to
know
what
is
the
end
user
allowed
to
make
questo?
Is
it
allowed
to
delete
collection?
Is
it
allowed
to
read?
Is
it
allowed
to
write?
B
So
this
is
a
simplified
example
of
how
you
can
enable
sto
are
back
service
to
service.
So
remember,
whenever
you
are
doing
are
back,
you
have
to
have
empty
LS,
enable
like
I,
was
saying
before
authorization
only
comes
in
after
authentication
and
for
authorization
to
make
sense
in
sto.
The
services
themselves
need
to
have
identities,
which
is
what
MPLS
gives
you.
B
If
you
don't
have
an
identity,
you
won't
be
able
to
authorize
them
so,
for
configuring
are
back
first,
you
can
do
for
the
first
you
need
to
do
is
enable
a
cluster
are
back
config,
which
tells
you
which
namespace
or
all
namespaces
you
want
to
include
or
exclude.
So
this
is
a
way
of
incrementally
adding
authorization
in
your
cluster
so
that
you
don't
turn
it
on,
and
then
everything
starts
working,
which
is
also
some
of
the
things
that
users
have
difficulty
with
when
they
arrest
you
soil
always
recommend,
add
authorization
incrementally.
B
So
when
you
add
authorization,
the
next
step
is
to
define
your
role
and
role
bindings.
So
a
service
role
is
akin
to
any
kind
of
role
which
you
can
define
in
kubernetes
or
you
can
define
elsewhere.
So
a
role
tells
you.
What
are
the
actions
you
are
allowed
to
make?
So,
in
this
case,
this
service
role
is
telling
that
your
it
is
allowed
to
do
a
get
request
for
any
service.
B
B
B
So
this
is
an
example
of
if
you
have
that
configuration,
what
your
envoy
configuration
will
look
like
remember,
pilot
will
take
all
the
resources
that
you
define
here,
lower
it
down
and
send
it
to
envoy.
In
this
case,
it
invokes
an
envoy
rback
filter,
which
you
see
in
the
top,
and
this
might
look
like
a
lot
of
policies
and
crazy
JSON,
but
it
actually
works
very
well
and
more
more
than
that,
you
are
not
configuring.
This
that's
the
beauty
of
ASPs.
You
are
actually
configuring
this.
So
what
this
is
telling
you
is.
B
There
are
set
of
principles
that
are
allowed
to
make
the
request
and
the
principles
have
to
have
these
reg
X's,
and
this
is
matching
what
you
did
in
the
earlier
slide.
So
next,
let's
move
on
to
when
you
want
to
do
authorization
from
end
user
to
services.
So
this
is
if
the
end
user
has
a
jar
token.
Normally
you
have
some
claims
stored
in
the
jar
and
you
want
the
services
to
enforce
our
back
based
on
those
charts.
B
Again,
you
can
do
this
in
your
application,
but
you
can
also
use
sto
configuration
to
handle
this
for
you.
So
for
enabling
a
car
back
from
end
user
to
service
it's
a
little
more
complex,
but
this
is
what
you
need.
First,
you
will
need
our
authentication
policy.
So
in
this
case
there
is
an
authentication
policy
just
like
before,
which
has
two
things
needs
to
have
MPLS
and
it
needs
to
have
a
section
for
jar.
Then
you
have
your
cluster,
our
bot
config,
which
is
included
for
some
namespace.
You
have
your
service
rule
like
before.
B
The
next
thing
is
you
treat
a
binding,
and
in
this
case
the
binding
is
different
than
your
earlier
service
role
binding.
So
this
binding
instead
of
using
the
subject
prod
source
namespace,
you
are
going
to
use
claims
directly
from
the
jar.
So
in
this
case
it
is
saying
if
the
jar
that
is
presented
is
showing
that
it
is
part
of
the
group
Group,
one
that
it
is
allowed
to
assume
the
role
of
SDB
bin
viewer.
So,
on
the
right
side,
you
are
seeing
a
jar
payload
which
will
actually
work
for
this
configuration.
B
So
if
your
jar
payload
has
groups
Group
one
and
group,
two,
this
request
will
make
it
to
the
application.
So
this
is
a
very
simple
way
of
making
sure
that
your
applications
never
get
requests
which
are
neither
authenticated,
not
an
authorized,
and
you
can
assume
that
all
the
requests
that
are
coming
to
your
application
container
are
ready
to
go
or
good
to
go.
B
So
if
you
do
this
kind
of
an
operation,
this
is
what
your
on.
Where
configure
it
eventually
look
like
so
in
this.
If
you
see
your
principles
and
now
saying
it
should
match
one
of
Group
one
and
the
path
is
from
the
request.
Earth
claims.
So
even
though
I've
given
you
an
example
of
group,
if
your
chart
has
some
different
fields,
for
example,
scope,
you
can
use
any
arbitrary
fields
from
the
jar
token
and
use
it
for
authorization.
B
The
next
thing
which
I
am
going
to
cover
is
the
sto
activate
based
access
control,
so
the
first,
the
former
concept
was
sto,
are
bad.
S2
also
provides
a
more
expressive
yet
more
complicated,
attribute
based
access
control.
So
the
way
that
works
is
whenever
a
request
reaches
a
sidecar
before
the
sidecar
forwards,
the
request
to
the
application
container.
It
makes
a
check
call
to
the
mixer.
B
During
this
check
called
the
sidecar
for
words,
various
attributes
of
the
request,
so
it
will
forward
where
the
client
is
server
is
what
are
the
request
parameters
like
the
method,
URL,
sighs
and
then
mixer
takes
in
various
steel
configuration
and
has
an
adapter
API
way.
It
can
invoke
any
third-party
adapters
for
enforcing
those
check,
calls
and
running
policies
on
that.
B
So
in
this
case
you
can
add
an
open
policy
agent
adapter,
which
is
a
flexible
policy
framework
which
still
provides
if
you
want
to
use
some
of
the
organization's
are
already
using
OPA
for
enforcing
policy
in
other
parts
of
the
system.
So
this
gives
you
the
flexibility
of
using
a
uniform
policy
language,
so
the
OPA
engine
for
in
this
example
we'll
run
the
policy
against
the
attitudes
that
you've
given
and
make
the
racial
just
or
no
send
the
region
back
to
the
sidecar,
and
then
the
side
cover
enforce
it.
B
So
if
the
reiation
is
yes,
it
will
forward
the
request
to
the
user
service
or
the
payment
service.
The
Dacian
is
knowing
you
rejected.
As
you
can
see,
there
are
some
problems
that
might
happen.
If
you
use
this
mechanism,
one
is
because
the
sidecar
is
making
out
of
process
calls
to
the
mixer.
You
can
have
additional
latency.
B
Obviously,
if
you
make
that
call
for
every
request,
this
system
is
not
tenable.
History
provides
a
caching
mechanism
where
the
sidecar
stores
the
results
of
the
policy
checks
and
if
this
based
on
attributes.
So
if
your
request
arrives
with
the
same
attributes,
your
caches
hit-
and
you
don't
have
to
make
that
call
again
for
from
where
I
stand
and
what
I
have
seen
most
of
the
users
only
need
the
cor
back.
They
are
good
with
doing
that,
and
but
if
you
need
some
more
advanced
functionality,
there's
always
a
CoA
back.
B
This
is
just,
in
my
opinion,
the
tip
of
the
iceberg,
a
lot
of
complicated
things
you
can
do
with
sto
by
combining
or
authentication
and
authorization,
so
some
applications
I
know
have
systems
where
they
have
charge
based
authentication,
but
then
they
also
have
a
separate
database
where
they
are
doing
authorization.
So
in
that
case
you
can
have
a
middle
layer
where
that
layer
can
get
the
authorization,
tokens
or
authorization
claims
from
the
authorization
DB
re-encoded.
B
So
the
last
thing
that
I
wanna
talk
about
is
a
zero
trust
network
and
basically,
what
I
want
to
say
is
this
is
a
concept
in
terminology
that
is
often
thrown
around
in
the
microservices
world.
It
is
based
on
the
principle
of
trust,
nothing
but
verify
everything.
So
basically,
what
you
want
to
do
is
even
if
the
request
originates
from
within
your
network
or
within
the
parameter
of
your
organization,
you
don't
assume
that
you
can
trust
it,
but
you
want
to
verify
it
based
on
what
the
credentials
are.
B
It's
easier
said
than
done,
especially
if
you
are
doing
this
in
your
own
applications.
This
is
where
I
think
the
real
benefit
of
is
to
you
in
a
service
mesh.
Is
you
can
use
sto
to
a
TN
the
principles
of
zero
trust
easily
by
doing
things
like
MPLS,
which
is
making
sure
that
now
you
have
identities
and
encryption
for
all
network
traffic?
You
can
you
can
enable
certificate
rotation
which
makes
it
more
secure,
which
otherwise
are
gained
difficult
to
do?
B
You
can
add
auditing
and
logging
by
just
toting
all
your
requests
in
the
form
of
traces
which
are
there
one
of
the
requirements
of
a
zero
trust
network.
Additionally,
you
can
implement
the
features
and
the
capabilities
of
a
zero
trust,
or
our
capabilities
of
least
principle,
of
least
privilege
is
by
adding
our
back
policies
again,
all
in
sto
or
a
service
mesh
without
doing
it
in
your
applications.
So
for
me
this
is
where
the
real
benefit
comes
in.
B
A
All
right,
well
that
presentation,
Arash!
Thank
you
outstanding
question.
I
encourage
others
to
come
in,
there's
a
question
with
respect
to
MPLS
and
it's
about
iteration
of
destination
rules
within
a
destination
rule.
There's
a
configuration
item.
The
host
attribute
normally
within
there
you'llyou'll
that
host
attribute
accepts
a
service
name.
So
the
question
is:
how
do
you
configure
the
client,
the
client
being
the
citecar
proxy
client
to
enable
in
TLS
to
a
specific
destination
pod
answer?
If.
B
Think
I
get
the
gist
and
thank
you
for
this
question,
and
this
is
one
of
the
real
difficult
issues
of
this
tier
when
it
related
to
the
api's.
So
when
you
are
configuring,
destination
rules,
you're
configuring,
the
client
side,
the
way
you
are
confirming
the
client
side,
you
are
saying
whenever
you
are
talking
to
this
service
via
host
name,
you
want
to
use
these
configuration
parameters
so
that
will
be
enforced
at
the
client
side
proxy.
B
When
you
are
configuring,
all
authentication
policy
or
MTA
or
mesh
policy,
those
things
will
be
in
force
at
the
server
side.
So,
even
though
you
are
not
using
a
client
workload
by
name
because
of
using
the
host
name,
whenever
any
request
is
invoked
with
that
host
name
automatically,
that
configuration
will
take
effect
on
the
client
side.
B
Thank
you
so
so
we
are
supported,
enterprise-grade
service
mesh
built
on
Sto,
so
we
help
companies
which
are
navigating
through
the
microservices
journey,
help
them
simplify
the
architecture
by
easily
adopting
a
service
mesh.
So
we
provide
support
for
them.
We
have
a
hosted
SAS
platform
which
lets
you
easily
configure
and
visualize
the
things
that
are
happening
in
your
cluster.
At
the
same
time,
we
provide
some
advanced
analytics
based
on
the
metrics
and
configuration
that
we
gather
from
your
cluster,
which
can
alert
you
and
tell
you
about
things
are
going
wrong.
A
B
A
B
A
B
A
B
Absolutely
I
think
that
is
one
of
the
things
that,
as
an
enterprise
supported
service
mesh,
we
are
trying
to
simplify
the
open
source
service.
Mesh
itself
allows
you
to
bring
VMs
or
use
things
like
configure.
I
think
that
now
not
running
in
your
continuous
environment
but
as
members
can
make
that
journey
simply
simpler
for
you.
So
what?
For
so
just
to
give
a
background
on
Aspen
mash,
we
are
an
incubation
out
of
f5
networks,
so
we
have
the
pedigree
of
working
with
enterprises
with
the
legacy
applications.
A
B
See
so
in
kubernetes,
when
you
are
defining
our
back,
you
are
defining
what
users
can
do
or
cannot
do
with
rady
to
the
kubernetes
api
server
and
the
kubernetes
resources
in
kubernetes
you're,
not
defining
our
back
for
service
to
service
communication
in
ISTE
or
that's
what
you
are
defining.
So
even
though
the
terminologies
overlap,
the
aim
and
the
intent
is
quite
different.
What
was
the
second
part
you
asked
Li
and.
B
So
there
are
numerous
types
of
admission
controllers:
in
SEO
itself,
you
have
the
sidecar
injector,
which
is
a
validating
and
a
mutating
admission
admission,
webhook,
so
admission
web
hooks
or
controllers
met
up,
makes
sure
that
your
configuration
that
you
are
applying
is
correct.
As
part
of
that
mission
controllers
also,
you
can
have
authorization,
but
again
that
is
orthogonal
to
how
traffic
flows
so
askew,
who
comes
in
after
you
have
configured
your
things
in
kubernetes.
It's
to
you
is
when
traffic
is
flowing
through
your
system,.
B
A
Topic,
certainly
a
hot
company
as
well
as
the
matters
with
that.
Just
a
reminder:
cannon
did
post
the
link
to
where
the
recording
will
be
and
the
slides
will
be
we're
a
little
bit
over
the
hour.
So,
unfortunately,
do
you
need
to
wrap
up.
Do
you
want
to
thank
neurons
very
much
for
today's
presentation,
very
informative
I?
Thank
you
all
for
joining
we'll
see
you
on
the
next
webinar.