►
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
Authentication and Security in gRPC Microservices - Jan Tattermusch, Google
Authenticating RPCs and securing them properly is crucial for building modern microservices. The talk will walk you through what gRPC has to offer in terms of authenticating and securing RPCs. It will explain the principles behind gRPC secure communication and show various approaches to authenticate your calls. It will also discuss the challenges of each approach. The principles will then be applied to demonstrate authentication in several scenarios in different kinds of deployment (including service-mesh). The examples will be focused on gRPC-based microservices in Kubernetes.
https://sched.co/MPbC
A
Okay,
all
right
have
a
look,
welcome
everybody,
I'm,
Doug,
Davis,
track
host.
Obviously
Yanis
gonna
be
talking
about
authentication
and
security
for
GR
PC.
Just
one
housekeeping
thing.
Please
try
to
remember
at
the
end
of
this
session
rate
it
through
the
app
itself,
so
the
organizers
can
know
whether
you
liked
it
dislike
tour
whatever
and
with
that
I'll
hand
it
over
to
yan,
to
give
us
take
it.
Okay,.
B
So
hello,
everyone,
thank
you,
hello,
everyone!
So
you
already
know
my
name
is
Yan
I'm
software
engineer
at
Google
I'm,
also
member
of
the
gr
PC
team
and
I'm
proud
owner
of
the
G
RPC
implementation
in
the
c-sharp
language.
So
today's
talk
is
called
authentication
and
security
in
G
RPC
micro
services.
So,
what's
it
gonna
be
about
first
I'll
show
you
some
of
the
basic
building
blocks
for
securing
G
RPC
services
and
I'll.
Show
you
how
they
fit
together
and,
oh
sorry,.
B
B
So
I'll
show
you
some
of
the
basic
building
blocks
and
how
they
fit
together.
Oh
I'll
start
with
the
very
basics
that
might
be
familiar
to
many
of
you,
but
I'll
later
get
into
a
little
bit
more
advanced
scenarios,
because
one
thing
is
knowing
the
concepts
and
the
other
one
is
securing
a
real
life
application.
B
Part
of
this
presentation
is
also
going
to
be
a
demo
and
in
the
demo,
I'll
focus
on
running
micro
services
in
our
kubernetes
cluster.
The
expectations
from
you
as
the
audience
is
that
you
already
know
what
G
RPC
is,
or
you
maybe
run.
Some
RPC
see
you
friend
the
hello
world
example.
You
know
some
of
the
basics.
You
know
just
how
to
get
around
with
your
PC.
B
B
So,
first
I
wanted
to
review
some
of
the
key
ideas
behind
the
G
RPC
security
design.
I
think
it's
very
useful
for
understanding
the
how
and
why
so,
oh
I
already
kind
of
said
that
building
authentication
and
security
is
a
lot
about
avoiding
mistakes.
So
when
our
building
G
RPC,
we
wanted
to
build
it
on
top
of
standard
and
proven
technologies
and
then
from
users
perspective
when
you're
actually
writing
the
code,
we
made
the
insecure
option
in
the
API
explicit.
So
that
means
when
you're
browsing
the
code
or
you
can
immediately
see.
B
Maybe
you
know
this
channel
is
so
set
as
an
insecure
Channel.
So
maybe
it's
not
such
a
good
idea
to
send
some.
You
know
sensitive
data
over
it.
Erp
C
is
so
also
multi-language,
and
so,
despite
every
every
language
being
different,
we
try
to
provide
a
unified
experience
or
and
kind
of
similar
feel
across
multiple
languages
or,
while
still
making
it
feel
natural
in
every
given
language.
B
So
the
approach
we
took
so
er
PC
is
extremely
versatile
Universal
and
can
run
on
multiple
platforms.
It
can
run
in
different
environments,
so
we
didn't
want
to
take
the
approach
of
basically
imposing
on
you.
What's
the
specific
authentication
solution
that
you
should
use,
but
rather
than
that,
we
provided
kind
of
a
general
framework
to
do
often
security
Wow
and
to
do
it
in
a
way
that
fits
your
use
case
and
then
the
specific
technical
solution
would
be
the
actual
off
method
that
you
choose.
B
B
The
community
helps
us
a
lot
with
that
and
there's
already
a
lot
of
blog
posts
around
a
RPC
authentication,
so
I
talked
about
using
standard
and
proven
technologies,
and
it's
pretty
well
known
that
G
RPC
is
actually
just
a
thin
framing
layer
on
top
of
the
HCP
2
protocol
version,
2,
oh
and
while
HTTP
2
is
still
relatively
new
HTTP,
as
a
protocol
has
been
around
for
a
long
time.
So
vast
amount
of
knowledge
and
experience
has
been
accumulated
around
authenticating,
our
HTTP
traffic
and
the
nice
thing
is
with
G
RPC.
B
This
knowledge
is
not
lost,
so
most
of
what
do
you
know
about?
Securing
HTTP
traffic
still
applies
for
G
RPC.
So
if
you
have
a
solution
that
already
works
for
HTTP
traffic
or
that
you're
familiar
with
chances,
are
that's
going
to
work
well
with
G
RPC
so
using
it
won't
feel
like
rain
wanting
the
wheel,
but
maybe
more
like
reapplying
common
knowledge
and
a
little
bit
of
a
new
context
and
I
have
a
little
table
here,
which
shows
so
the
basic
concepts
I'm,
not
sure.
B
Okay,
laser
pointer,
probably
cannot
be
seen
so
on
the
left
side.
There's
a
there's.
The
HTTP
do
concept
so
when
you're
doing
a
connection
level,
security,
so
basically
encrypted
connections
with
HCP
that
corresponds
to
using
a
so-called
secure
channels
in
G
RPC
and
whenever
you're,
using
request
headers
for
authentication,
that's
going
to
correspond
to
something
that's
called
initial
metadata
and
just
as
with
request
headers.
The
RPC
metadata
is
actually
multi-purpose,
so
it
can
be
used
for
all,
but
it
can
be
used
for
other
things
too.
B
So
I
kind
of
already
started,
but
here's
the
10,000
feet
view
of
what
exists
in
the
world
of
G
RPC
authentication.
So
the
first
option
is,
you
can
authenticate
individual
remote
calls
and
the
way
it
works
is
you
at
a
secret
token,
in
your
cost
method,
a
DES,
and
this
token
allows
the
other
side
to
verify
that
you
are
here.
You
claim
to
me
and
possibly
to
verify
some
other
claims
and
to
be
able
to
send
the
secret
token
over
the
wire.
B
This
means
you
basically,
when
you
start
your
communication,
you
establish
an
encrypted
connection
with
with
the
peer
and
one
or
both
sides
authenticate
their
peer
during
the
initial
handshake
and
after
that,
that
channel
is
known
to
be
trusted,
and
you
know
that
the
data
is
coming
from.
The
other
side
you
know
is
from
who
you
expect
it
to
be
the
standard
way
to
achieve.
This
is
through
transport
layer,
security
for
G
RPC.
B
There
are
other
ways
to
there
are
other
transport
or
besides
TLS
or
but
it's
a
little
bit
out
of
scope
for
for
this
talk
or
RPC.
Also,
it's
also
extensible,
so
it's
possible
to
add
new
transport,
but
that's
so
that's
kind
of
a
big
investment.
It
requires
little
effort,
so
it's
definitely
not
recommended
for
99%
of
the
users.
B
That's
actually
a
nice
way
to
decouple
your
business
logic
and
the
security
layer
itself.
Oh,
and
it
comes
handy,
especially
when
building
micro
services,
because
with
micro
services,
you're
gonna,
have
multiple
smaller
components
and
in
those
components
you
probably
want
to
focus
on
business
logic
more
then,
then,
on
the
authentication
itself,
and
then
you
basically
just
want
to
add
some
or
layer
on
top
of
it.
That
is
gonna,
that's
gonna
magically
add
the
authentication
and
security
capabilities.
B
So
let's
take
a
closer
look
at
the
per
call
authentication
with
tokens.
So
in
this
context,
when
I
talk
about
tokens,
I
have
the
bearer
tokens
in
mind.
So
the
name
bearer
comes
from
the
HTTP
or
Bearer
authentication
scheme,
and
what
it
means
is
is
basically
oh
wait
when
you're
sending
the
the
bearer
token,
what
you're
saying
is
basically
give
access
to
some
resource.
To
bearer
of
you
know
this
specific
token
that
I'm
sending
around
the
tokens
come
in
many
kinds.
B
They
usually
look
like
cryptic
strings,
they're,
usually
base64
or
some
other
encoding,
but
the
ones
you'll
see
the
most
commonly
is
earth-2
and
jot
tokens,
or
the
main
difference
between
those
is
that
auth
2
is
an
is
an
opaque
token.
It's
so
usually
emitted
by
a
third
party,
so
you
reach
out
to
to
some
other
party
or
you
provide
some
credentials.
You
get
the
two
token
in
exchange,
you
send
it
along
with
your
RPC
calls
and
then
on
the
server
side
once
that
tokens.
B
Once
that
token
is
received
you
reach
out
to
the
third
party
again
to
actually
verify
you
know
that
that
token
is
actually
valid
and
allows
access
to
even
resource
the
JSON
web
token
also
called
jot
is,
is
different
in
the
sense
that
is,
it
is
self-contained
and
it
does
three
parts.
One
of
them
is
header,
which
is
not
really
important
right
now.
The
other
part
is
the
actual,
is
the
actual
token
that
contains
some
some
data
that
it's
claiming
about
the
owner
of
the
token
and
the
last
part
is
signature.
B
Soja
tokens
are
self-contained
in
the
sense
that
when
you
received
the
Jo
token,
you
can
just
verify
the
cryptographic
signature
of
that
token,
and
you
know
if
it's
valid
or
not.
Oh,
because
I'm,
a
G,
RPC
maintainer
I've
been
following
some
of
the
public
forums
and
user
questions
a
lot,
so
it
also
turned
out
that
some
of
the
people
actually
think
that,
when
talking
about
tokens
like
sending
a
password
over
in
the
metadata
is
a
you
know
get
good
idea,
and
it
qualifies
the
token.
So
please
don't
do
that.
Oh
it's!
B
B
Another
interesting
thing
to
note
is
that
it
seems
that
when
I'm
sending
an
authentication
token
along
with
my
RPC
call,
I'm
basically
gonna
be
sending
you
know
the
data
over
and
over,
and
especially
for
the
jot
tokens
that
can
be
sizable.
That's
gonna
be
a
performance
overhead,
but
it's
actually,
it
turns
out
not
to
be
a
problem,
because
the
HTTP
to
implements
something,
that's
called
HVAC
and
it's
a
scheme
for
a
compression
of
the
headers.
B
So
when
you're,
when
you're
sending
the
same
authentication
token
over
and
over
with
the
with
calls
or
HVAC,
is
actually
gonna
compress
that
away
and
you're,
not
you're,
just
gonna
be
sending
like
a
reference
to
your
compression
table,
okay
over
to
securing
channels.
So
the
concept
of
a
channel
exists
in
all
G
RPC
implementation,
patience
or
for
simplicity
or
the
GRP.
See.
Connections
are
just
HTTP
to
connections
and
there
are
actually
two
kinds
of
there
are
two
main
kinds
of
ERP
C
secure
channels.
B
So
one
allows
the
client
to
verify
that
it's
talking
to
the
right
server
and
the
other
method
is
where
both
sides
mutually
authenticate
each
other,
that
they
don't
know
that
the
counterpart
is
with
who
it
claims
to
be
note
that
there's
no
variant
where
none
of
the
parties
authenticates
authenticates
each
other,
because
that's
basically
useless
in
practice.
So
if
you're,
establishing
a
secure
channel,
you're,
probably
gonna
be
sent
sending
some
confidential
data
and
unless
you
know
what
who
the
other
side
is,
there's
there's
no
point
of
doing
that.
B
So
the
way
it
works
with
TLS,
which
is
the
transport
layer,
security
and
it's
the
same
idea
as
with
HTTP
to
connections,
is
that
the
client
has
certificate
authority
routes
and
the
server
has
a
certificate.
I
know
private
key
and
then
using
the
certificate
authority.
You
can
verify
the
client
or
during
the
initial
handshake
and
verify
that
it's
talking
to
the
right
server
and
mutual
TLS
is
kind
of
a
similar
idea,
but
the
server
also
has
the
certificate
authority
and
the
client
has
a
certificate
on
its
own
and
a
private
key.
B
So,
basically,
they
can
verify
that
the
certificate
authority
has
signed
the
certificate
of
the
other
side
and
then
it's
basically
genuine
okay.
So
mutual
TLS
is
so
it's
great
and
very
secure
if
done
right,
but
unfortunately
it
requires
certificates
to
work
so
and
the
certificates
they
are
easy
to
generate
when
you're
coming
up
with
tests.
When
you're
writing
your
prototypes,
but
it
becomes
much
more
challenging
when
running
a
real
application
in
production
and
the
reality
is
that
your
MPLS
secure
authentication
scheme
is
so
it's
only
going
to
be
as
secure
as
your
key
management
practices.
B
So
if
you
rely
on
your
private
keys
and
for
authentication
and
then
the
keys
leak,
you
know
you're
basically
done
so
one
of
the
practices
that
you
know
are
recommended
or
is,
for
example,
the
certificate
rotation.
So,
even
in
the
case
when
the
attacker
gets
access
to
your
to
your
private
keys
and
the
certificates,
oh,
they
can
only
use
it
for
limited
amount
of
time
and
if
you're,
managing
your
certificates
yourself
and
you're,
trying
to
do
things
like
certificate
rotation
and
do
it
like
every
day.
Oh,
it's
very
easy
to
mismanage
and
then
you're.
B
Basically,
opening
up
opening
up
yourself,
for
you
know,
security
risks.
So
ideally
we
would
want
a
solution
that
can
do
mutual
TLS,
but
takes
away
the
pain
of
and
risks
associated
with.
Certain
management
and
the
good
news
is
such
solution
exists,
there's
actually
multiple
solution,
but
but
one
of
them
is
using
a
service
match.
That's
called
a
steal.
B
So
before
explaining
how
the
steal
authentication
works.
It's
worth
mentioning
of
a
few
useful
primitives
that
are
provided
by
kubernetes
itself
as
building
blocks
for
a
steal
authentication,
and
these
primitives
can
be
actually
used
in
simpler
applications
separately
as
well.
So
whenever
you're
working
with
authentication,
there
is
necessarily
gonna,
be
some
secret
that
one
of
the
parties
needs
to
have
in
order
to
prove
to
the
other
side
that
you
know
it's.
B
Whenever
you
create
a
kubernetes
service,
you
specify
it
should
have
access
to
given
secret
and
then
kubernetes
transparently
mounts
that
secret
to
your
container
kubernetes
service
accounts
are
useful
for,
like
they're,
basically
a
secure
way
to
represent
identities
in
your
kubernetes
cluster,
so
with
steel
and
it's
the
authentication,
two
main
components
come
into
play.
One
of
them
is
pilot
and
that's
basically
the
component.
That's
knows
about
your
services
in
your
cluster
and
from
the
kubernetes
service
accounts.
B
It
can
establish
identities
of
those
services
and
Citadel
is
kind
of
the
key
and
certificate
management
of
heavy
lifting
part,
so
that
one
actually
managed
manages
and
rotates
the
TLS
certificates.
And
then
the
last
piece
of
the
of
the
puzzle
is:
are
the
envoi
proxies
that
are
deployed
as
sidecar
proxies
with,
along
with
your
services,
and
these
Android
proxies
obtain
the
certificates
and
and
private
keys
in
form
of
a
kubernetes
secret,
and
they
establish
the
mutual
TLS
authentication
transparently
between
services?
B
B
B
Okay,
so
what
I
have
here
is
so
is
so
basically
an
example
of
kubernetes
cluster
or
nothing
is
currently
running
there.
We
can
make
sure
that's
actually
the
case,
so
it's
just
a
regular
kubernetes
cluster.
So
what
I'll
have
is
a
client
that
is
very
simple
and
the
only
thing
it
does.
It
creates
a
channel
and
it
passes
so
called
channel
credentials.
B
B
So
I'm
gonna
show
you,
so
this
is
the
method,
that's
creating
the
credentials.
In
the
first
example,
the
mutual
TLS
is
going
to
be
not
used.
So
the
only
thing
we
basically
do
is
create
the
SSO
credentials
and
we
pass
in
the
certificate
authority
which
is
going
to
be
used
to
verify
that
we're
talking
to
the
right
server
and
besides
that
I
have
a
server.
That's
also
very
simple.
B
So
for
the
and
you
can
see,
the
implementation
of
the
server
is
basically
just
start.
The
server
on
a
port
provide
some
kind
of
credentials
and
they're
gonna
be
different,
based
on
each
case
in
the
example
and
then
for
the
case,
where
we're
not
going
to
be
using
mutual
TLS.
Yet
so,
just
a
regular
TLS
we're
gonna
be
providing
the
server
side
so
certificate
and
the
corresponding
private
key.
So
I
can
now
go
ahead
and
deploy.
B
I'm
also
going
to
be
adding
so-called
call
credentials
and
my
oath
auth
interceptor
is
going
to
be
adding
a
initial
metadata
entry
with
the
key
authorization
and
then
at
the
bearer
token,
which
is
going
to
be
a
job
that
I
just
generated
and,
in
my
example
generating
the
job
is
pretty
simple,
but
you
can
see
that
I'm
generating
a
job
that
is
so
expiry
or
it
has
so.
It
is
a
subject
which
is
me
and
it
is
audience
and
it's
intended
for
the
helloworld
service
and
then
on
the
on
the
server
side.
B
Okay,
so
that's
jot.
The
next
example
is
going
to
be
using
mutual
TLS,
oh
and
this
time
we'll
need
to
replace
the
server,
because,
right
now
the
current
server
doesn't
have
the
certificate
authority
specified
and
it.
So
it's
not
verifying
that
it's
connected
that
the
connected
client
is,
is
the
one
that's
allowed
to
connect.
B
So
I'm,
basically
just
going
to
replace
the
existing
server
with
with
the
one
that
uses
M
TLS
and
what
is
good.
What
what
this
is
going
to
do
with
the
server
is,
besides
the
certificate
and
the
private
key,
it's
also
going
to
specify
the
certificate
authority
that
should
be
used
to
verify
the
client
on
the
client
side.
I'll
need
to
provide,
besides
the
certificate
authority
that
I
already
provided
I'll
need
to
provide
the
client-side
certificate,
which
is
now
going
to
be
verified
and
the
corresponding
private
key.
B
B
So
so
the
way
it's
going
to
work
is
so
that
I
specify
a
server.
That's
actually
uses
no
security
at
all,
but
I'm
also
going
to
use
the
sto
CTL
command
to
inject
the
sidecar
proxy
and
the
sidecar
proxy
will
take
care
of
actually
establishing
the
mutual
TLS
connection.
So
I'm
gonna
replace
the
existing
server.
A
B
I'll
need
to
there's
actually
two
containers
running
in
my
pot.
One
of
them
is
the
actual
greeter
client
and
the
other
one
is
the
steel
sidecar
Pro
is
the
invoice
ID
card
proxy,
so
you
can
see
that
the
client
can
connect
to
the
server
and
the
way
to
verify
that
it's
actually
authenticate
'add
via
mutual
TLS.
B
B
So
I'm
gonna,
thank
you
for
attention.
Oh
and
before
you
ask
any
questions.
I
just
wanted
to
give
a
shout
out
to
vicious
talk
tomorrow.
It's
going
to
be
about
ERP,
C
load,
balancing
it's
in
the
CTO
room
or
if
you
want
to
chat
with
me
personally
or
you
know,
chat
with
other
people
that
know
about
gr
PC.
Please
meet
me
at
the
CN
CF
answer
bar
on
Thursday.
Oh
it's
in
the
sponsor
showcase
hall
or
you
can
just
chat
to
me.