►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
gRPC Proxyless Service Mesh with Security - Sanjay M Pujare, Google
gRPC has been a popular choice for building microservices based service mesh architectures especially after the recent introduction of service mesh features such as service discovery, load balancing, and observability which eliminated the need for sidecar proxies - like Envoy - in the service mesh. The introduction of these features in gRPC enabled a "proxyless service mesh". In this session we will talk about the addition of mTLS based transport security to the proxyless service mesh. We will describe the orchestration of security by the xDS control plane, the addition of a security plugin architecture to gRPC, and the implementation of some of those plugins to take advantage of security infrastructure in the Google Kubernetes Environment (GKE).
A
A
In
this
talk,
I'm
going
to
cover
a
grpc
proxima
service,
mesh,
intro
and
summary
I'll
also
talk
about
why
we
need
security
in
the
service
mesh
and
why
is
it
so
painful
today
I'll
talk
about
how
we
added
security
to
the
grpc
proxima
service
mesh
and
how
it
works
I'll
I'll?
Do
a
technical
drill
down
with
a
deployment
diagram?
A
Then
I'll
talk
about
what
changes
we
made
to
the
grpc
library,
specifically
the
grpc
programming
api,
for
using
this
feature
and
later
on
I'll
I'll,
basically
describe
a
psm
security
deployment.
What
it
looks
like
in
google
cloud
as
an
example
towards
the
end
I'll
cover
the
future
roadmap,
and
I
also
have
a
slide
that
has
some
links
to
resources
for
psm
in
case
you're
interested
and
towards
the
end.
You
know
we'll
have
a
few
minutes
for
a
q,
a.
A
Now
I'll
give
a
brief
intro
to
service
mesh,
so
service
mesh
with
proxies
was
the
initial
model.
This
is
how
the
service
mesh
started
in
this
transparent
proxies
in
red
boxes,
allow
existing
applications
to
be
in
a
service
mesh.
The
applications
shown
in
blue
boxes
are
not
aware
of
the
service
mesh.
A
A
A
A
Let
me
talk
about
xts,
because
xdf
frequently
mentioned
in
the
context
of
service
meshes
xds
is
a
protocol
for
control
plane
to
talk
to
data
plane
entities.
Hence
it's
called
a
data
plane.
Api
xts
where
x
stands
for
something
like
an
unknown
quantity
in
equations
and
ds
is
discovery
service
so
like
discovery
of
clusters,
routes
and
listeners,
etc.
A
A
So
when
the
pandemic
was
reaching,
we
were
enhancing
the
proximal
service
mesh
with
grpc.
Our
first
release
last
year
in
june,
had
basic
load,
balancing
and
service
discovery.
Over
the
past
year,
we
added
various
advanced
traffic
management
features
like
traffic
splitting
circuit
breaking
and
session
affinity.
A
A
So
so
far,
I've
talked
about
just
proxy
service
mesh
without
security,
so
just
to
recap:
proxima
service
mesh,
the
current
status-
and
there
was
a
previous
kubecon
presentation
by
our
product
manager,
megan
in
may
earlier
this
year
that
talks
about
the
grpc
proxy
service
mesh
and
what
we
had
until
then.
You
know
basically
the
load,
balancing
plus
advanced
traffic
management
features,
so
I've
included
links
to
the
slide
set
and
the
video
recording
here
at
google's
traffic
director
side.
A
There
are
a
couple
of
blogs
that
talk
about
this.
Now,
traffic
director
is
google's
implementation
of
the
xds
control
plane.
The
traffic
director
user
guide
covers
proxima
service
mesh
and
you
can
actually,
you
know,
get
a
test
account,
I
believe,
with
some
free
credits
on
google
cloud
and
and
do
a
test
drive
of
the
proximity
service
mesh.
A
Now
before
I
go
into
proxy
service
mesh
security,
I
I
kind
of
wanted
to
summarize:
why
is
security
so
important
in
service
mesh
right
now?
You
can
think
of
a
service
mesh
as
the
equivalent
to
breaking
up
a
monolithic
application
and
what
used
to
be
in
process
communication
inside
the
monolith
is
now
rpcs
over
the
network
and
as
a
result
of
that,
these
rpcs
need
to
be
secure.
A
A
Now
all
of
these
things
ultimately
enable
a
secure
service
mesh.
There
is
another
point
I
kind
of
want
to
make
in
passing
for
a
real,
effective
security.
We
also
need
a
certificates
and
keys
to
be
rotated.
Do
we
want
to
burden
the
application
developers
with
the
overhead
of
certificate
and
key
management
for
doing
that?
No,
so
we,
ideally,
we
would
like
the
infrastructure
and
the
framework
together
to
do
these
things
for
us
and
that's
where
psm
security
comes
in.
A
You
first
of
all
have
to
modify
the
code
to
load
certificates
and
use
them
to
create
a
tls
or
mpls
connection.
Then
you
also
have
to
add
code
to
perform
additional
verification.
As
per
your
semantics,
for
example,
only
certificates
with
certain
identities
are
allowed
for
certain
services,
and
also
it's
a
headache
for
folks
deploying
and
configuring
your
software.
You
know
they
need
to
manage
things
like
you
know.
A
A
A
A
The
xts
control
plane
is
needed
to
orchestrate
and
secure
connections
between
the
workloads
by
providing
the
security,
configuration
and
grpc
is
the
glue
that
combines
infrastructure,
provided
certificates
and
keys,
xds
control
plane
provided
security
configuration
and
it
kind
of
putting
it
all
together.
It
makes
the
traffic
secure.
A
A
A
Both
the
client
and
server
are
xds
enabled
and
get
their
security
configuration
from
the
xds
control
plane
shown
in
blue
at
the
top.
The
client
and
server
needs
certificates
and
keys
that
are
provided
by
the
underlying
infrastructure.
To
make
it
all
happen.
The
green
box
represents
the
infrastructure
components
which
include
the
certification
authorities
or
cas
to
mint
the
certificates
and
a
process
to
continuously
generate
csrs
and
to
use
them
to
request
certificates
and
a
mechanism
to
make
these
certificates
and
keys
available
to
the
grpc
workload
using
grpc's
plugin
feature.
A
A
I
have
three
columns
here,
one
for
the
client
on
the
left,
one
for
the
control
plane
in
the
middle
and
one
for
the
server
on
the
right.
This
shows
the
configuration
steps
from
the
control
plane
here.
The
client
is
trying
to
reach
something
like
a
payment
dot
service
and
uses
xts
colon
slash,
slash
payment.service
as
the
target
string.
A
A
One
instance
here
here
is
here
with
the
ip
address
10.3.9
and
a
certificate
id
of
mesh
one
slash
cluster
to
slash
srv3
I'll
I'll
talk
about
spf,
the
spf
colon
prefix
later,
but
over
here
on
the
right.
The
server
in
the
red
box
receives
lds,
which
is
a
listener
discovery
service
message
to
help
it
set
up
the
listener
socket
for
the
service.
A
When
the
server
receives
a
client
connection.
The
server
applies,
what
is
called
a
filter
chain
from
xts
and
that
filter
chain
contains
the
required
tls
configuration
for
the
transport
socket.
Now
the
idea
of
interchange
is,
you
can
actually
have
different
security
configuration
for
different
clients,
so
the
filter
chain
has
a
filter
chain
matcher,
and
you
know,
based
on
the
matching
that
is
happening,
the
server
is
able
to
actually
use
different
security,
configuration
for,
let's
say
different
ip
addresses,
different
networks
and
all
that
stuff.
A
Of
mesh
one
slash
cluster,
two
slash
srv3:
this
is
just
a
made
up
id
for
the
current
client
connection.
So,
as
you
see,
both
the
client
and
the
server
receive
the
required
configuration
to
set
up
mtrs
connections
between
them.
So
this
configuration
enclosed
things
like
the
certificate
and
keys
whether
it
should
be
a
tls
mode
or
an
mpls
mode
connection
and
server
authorization.
Information
again,
like
I
said
earlier
I'll
talk
about
several
authorization
in
a
bit.
A
A
A
A
The
pipeline
is
a
dynamic,
which
means
when
certificates
and
keys
are
updated.
The
updates
are
immediately
reflected
in
the
channel
or
the
server
now.
This
simplified
interface
allows
both
envoy
and
grpc
to
use
this
interface,
and
this
is
made
possible
because
of
the
interaction
provided
between
the
implementation
and
the
xds
protocol.
A
Some
more
stuff,
this
is
a
pictorial
representation
of
the
certificate
provider
plugin
framework
and
how
it
works.
A
channel
in
the
blue
box
on
the
left
is
configured
by
xds
credential,
the
same
thing.
On
the
server
side,
a
server
connection
which
is
shown
in
in
the
yellow
box
is
configured
using
nxts
credential.
A
It
sets
up
a
pipeline
for
the
certificate
provider
to
provide
dynamic
certificate
updates
to
the
tls
handshaker,
so
the
certificate
provider
continuously
get
periodic
updates
and
certificate
updates
and
gives
it
to
the
handshaker.
The
advanced
stairs
handshaker
is
responsible
for
channel
or
the
server
connections
tiers,
handshake
based
on
the
the
certificates
provided
by
the
certificate
provider.
A
A
We
have
a
new
xts
implementation
of
what
is
called
a
transport
socket
config
in
grpc.
We
also
implemented
the
certificate
provider
plugin
framework
and
how
it
is
indirectly
referenced
via
xds
in
grpc.
We
also
extended
the
bootstrap
file,
schema
to
add
fields
required
by
the
certificate
provider
plugin
framework
and,
of
course,
as
part
of
that,
we
also
implemented
the
file
watcher
certificate
provider,
plugin,
which
supports
dynamic
certificate
and
key
updates
of
file-based
certificates
and
keys.
A
Now
let
me
talk
briefly
about
spacey.
I
had
mentioned
the
pc
earlier
for
service
identities.
Now
this
is
not
really
a
grpc
thing,
but
this
is
a
new
spec
or
standard
for
identities
in
a
service
mesh,
so
a
species
service
identity
is
assigned
to
a
microservice
and
encoded
in
the
services
certificate
and
the
service
uses
the
certificate
both
on
its
outbound,
which
is
on
the
client
side
and
the
inbound
or
the
server
side.
A
The
trust
domain
in
is
an
identifier
for
the
trust
infrastructure
and
in
google
cloud
it
is
typically
the
google
cloud
project
id,
because
the
trust
infrastructure
is
associated
with
the
project.
The
google
cloud
project
and
the
the
rest.
The
remaining
part
of
this
pc
identity
is,
is
a
unique
identity
for
the
service
and
in
our
implementation
with
gke.
It
typically
is
the
kubernetes
namespace
name
and
the
service
account
the
kubernetes
service
account
for
that
particular
part.
A
A
A
A
Now,
xts
channel
credential
is
a
way
for
a
caller
to
obtain
the
use
of
xts
security.
Configuration
note
that
a
caller
can
use
a
different
credential,
for
example,
tls
credential,
with
a
channel,
in
which
case
the
xts
supplied
security
configuration
is
ignored,
even
if
for
routing
load,
balancing,
etc.
The
x-rays
configuration
is
used
now
in
this
example,
because
of
the
xds
current
scheme
used
in
the
target
string,
xds
code
payment.service,
the
xts
name,
resolver,
and
eventually
the
xts
load,
balancing
routing
config
is
used,
but
the
security
configuration
from
xds
is
not
used.
A
Something
about
these
notion
of
fallback
credential.
So
an
xts
credential
also
takes
something
called
a
fallback
credential
which
kicks
in
if
xds
doesn't
supply
a
security
configuration.
So,
instead
of
choosing
to
treat
this
as
a
plain
text
or
insecure
communication,
a
caller
can
tell
grpc
to
use
the
fallback
tls
credential,
as
I
have
shown
here,.
A
Like
I
mentioned
earlier,
you
can
get
a
test
account
on
google
cloud
and
use
the
traffic
director
user
guide,
with
the
section
that
talks
about
proxima
service,
mesh
security
and
try
this
out
the
main
elements
of
this.
This
offering
is
traffic
director
the
xcs
control
plane,
something
called
google
cas,
which
is
certification,
authority
service,
then,
of
course
gke,
which
is
the
compute
engine
or
the
compute
infrastructure
you
have
to
use.
A
A
A
I
have
provided
a
link
here
and
there
is
something
new
called
a
specie
federated
trust
bundle
for
proper
federation
or
as
per
the
species.
Spec
in
this,
what
happens
is
there
is
a
map
of
a
trust
domain
to
root
certificate
so
that
you
don't
use
the
same
root
certificate
to
validate
all
the
trust
domains,
most
probably
will
use
something
called
a
configurable
certificate
validator,
which
is
an
xts
extension
point
to
support
this
federation
of
trust
domains.
A
A
A
So
this
is
my
last
slide,
basically
has
links
to
various
resources
to
get
more
information.
The
five
grfcs
psm
security
java
channel
server
credentials,
and
you
know
stuff,
like
oddsy,
that
I
talked
about
then
couple
of
links
to
a
google
cloud
blog
for
an
intro.
This
feature
in
the
context
of
google
cloud
and
of
course
there
is
the
traffic
director
user
guide
for
traffic
for
security
with
proxies
service
mesh
using
grpc.
C
So
we've
got
just
a
couple
of
minutes
for
for
questions
here,
maybe
I'll
throw
a
couple
from
online.
If
that's
right,
yeah
there's,
I
think,
maybe
for
some
of
the
folks
newer
to
grpc
some
questions
about.
How
does
the
the
effort
here?
Is
it
something
that
can
be
abstracted
to
other
environments
or
is
it
just
specifically
for
grpc
any
support
for
http
2
things
like
that
in
the
mesh
side
of
things.
A
A
B
B
A
I
mean
I
talked
about
google
cloud
implementation,
because
that
is
something
that
has
been
tested
and
works
and
all
otherwise
everything
we
have
done
is
conforming
to
the
xds
protocol.
Without
any
google
specific
extensions
or
google
specific
implementation,
so
yeah
you
can
you
can
take
a
a
control
plane.