►
From YouTube: Deep Dive Into Building a Secure & Multi-tenant SaaS Solution with NATS - Wally Quevedo, Synadia
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Deep Dive Into Building a Secure & Multi-tenant SaaS Solution with NATS - Wally Quevedo, Synadia
The NATS project turns 10 in 2020, and what started as a simple and high performance messaging system written in Go to build event-driven architectures using Pub/Sub, has since then evolved into a component that can allow the seamless communication of streams & services across multiple regions, thus simplifying further the stack required to deploy globally available services. In this talk, you will learn from one of the maintainers of the project how to create applications in Go that take advantage of NATS messaging and security features by demonstrating how to implement a minimal chat application that is secure and globally available.
https://sched.co/Zext
A
Hello,
this
is
the
nuts
deep
dive
2020..
This
is
about
building
decentralized
applications
and
using
nets.
My
name
is
valde
marquevedo,
one
of
the
core
maintainers
from
next.
I
have
been
using
nuts-based
platforms
for
a
number
of
years.
I
also
wrote
a
book
two
years
ago
about
it's
called
practical
nets
and
it
covers
a
lot
of
the
features
and
the
api
from
nasa
v1,
especially
we're
currently
at
nats
version,
2
and
also
working
at
cynidia
building
and
that's
a
global
service.
A
So
in
this
talk
I
wanted
to
give
a
kind
of
a
deep
dive
and
internals
from
a
chat
application
that
is
using
some
of
the
security
features
from
nets
to
build
a
decentralized
chat,
application
that
new
users
can
kind
of
join
in
and
then
have
their
present
secure
credentials
be
provisioned
on
the
fly
all
this
repo.
All
this
code,
you
can
find
it
at
the
repo
the
yqs
cubecon
2020,
so
you
can't
use
that.
Try
use
the
examples
on
your
own
as
well.
A
A
So
one
quick
recap
about
nets,
strings
and
and
services.
So
nets
is
a
publisher
skype,
pure
published
scribe
system.
So
everything
is
a
pops
up,
and
the
protocol
itself
has
not
changed.
Pretty
much
has
not
changed
in
in
a
decade
since
when
the
project
started
but
published
subscribe
are
more
like
terms
of
the
api
level.
So
when
we're
talking
about
building
applications,
we
really
want
to
talk
about
that.
A
How
we're
using
a
stream
of
events
or
how
we're
using
a
service
and,
throughout
this
talk,
we're
gonna
be
being
very
explicit
in
what
is
a
stream
in
in
terms
of
this
application
and
what
is
a
service,
a
stream?
You
could
say
it's
like
a
a
flow
or
just
a
sequence,
sequence
of
events
that
can
be
found
out
to
a
multiple
of
consumers.
A
A
service
is,
on
the
other
hand,
something
that
can
take
a
message
and
also
respond
to
that
message.
Using
the
q
subscribes
api
from
nets,
they
become
load
balanced
for
free.
You
know
how
that's
why
you
don't
need
extra
load
balancers
when
using
nets,
but
the
idea
is
that
with
services
they
take
requests
and
they're
able
to
have
responses.
A
A
All
of
these
subjects
and
walkers
are
used
as
internally
and
nets
clients
to
create
inboxes,
unique
inboxes
as
well,
which
is
how
the
requests
work
so
streams
and
services.
They
both
use
subjects
in
this.
In
this
example
on
the
left,
we're
using
the
accounts
isolation.
So
we
have
a
couple
of
accounts
that
it
one
is
exporting
a
stream
from
the
acme
account
to
the
cncf
account
you
can
see
here
that
is,
is
importing
from
the
acme
account.
A
This
subject
matching
anything
on
this
wildcard
when
we're
talking
about
the
streams,
the
apis
that
we
are
going
to
be
using,
are
publish
and
subscribe,
mainly
so
here,
the
exporter
of
the
survey
or
this
other
stream
and
it's
gonna
be
producing
events
publishing
on
the
acme,
dot,
hello
and
then
they're
from
the
other
account
we're
gonna
be
importing
into
this
prefix
import.
prefix,
any
event
that
has
been
published
by
this
other
account.
A
So
that's
an
example
of
isolated
streams
between
different
accounts
with
that
v2.
It's
very
useful
that
you
can't.
I
just
have
these
subject
name
spaces
for
for
the
streams
and
data
sharing
and
besides
streams,
we
also
have
the
the
services
and
the
services
at
the
nets.
Api
label
we're
talking
about
both
using
that
subscribe,
something
that's
going
to
handle
a
message
recommended
to
use
a
q
subscription
so
that
they
become
load
balance
out
of
the
box
and
it's
gonna
respond
or
publish
into
the
subs
inbox
for
this
particular
message.
A
A
A
So
in
this
case
the
answer
is
gonna
match
to
the
room
in
this
case,
for
it
could
be
kubecon.
That's
general
we'll
also
have
support
for
direct
messages.
The
direct
messages
is
also
a
wild
card
from
any
from
from
the
subject,
and
also
the
three
of
the
list
of
users
that
are
available,
they're,
going
to
be
represented
as
heartbeats
that
are
critically
sent
to
this
chat,
dot
coupon
online
stream.
A
So
all
of
these
are
streams
when
we're
actually
using
the
application
when
services
come
into
the
picture
is
when
you
need
to
make
a
a
new
user.
You
need
to
make
a
new
user
request
through
nets
to
another
service.
That
is
available
from
within
nets
that
you
can.
You
can
send
in
a
request,
to
get
a
new
pair
of
credentials
to
be
able
to
get
into
the
be
part
of
the
this
nuts
chat
system.
A
So
you
have
three
streams
and
one
service
for
this,
and
there
is
no
single
central
chat
server
on
anything.
Everything
is
on
there
part
of
the
client
logic,
so
you
have
a
three
different
types
of
users
that
we
will
need
to
create
because
we
want
to
have
the
proper
permissioning
and
data
sharing
between
the
users
there.
A
A
To
create
all
the
accounts
and
users
will
be
using
nsc
now,
nsc
is
the
tool
that
you
can
use
to
manage
users
when,
on
the
jwts,
from
a
net
system
on
whether
it's
using
when
it's
running
in
trusted
operator
mode.
So
in
this
script,
if
you
can
it's
just
ns
nsc
being
initialized
to
create
a
new
operator
jwt
that
is
going
to
be
used
for
adding
new
accounts
and
users.
A
A
A
Creating
well
for
signing
users
for
current
users,
so
nsc,
and
we
edit
the
account
jwt
to
be
able
to
have
a
new
signing
key
and
now,
if
we
inspect
the
jwt
from
the
kubecon
account
we'll
see
that
now
we
have
this
public
key
as
part
of
the
jwt,
from
the
account
we'll
use
this
nsc
again
to
generate
the
configuration
for
the
net
server.
So
this
is
gonna,
create
a
memory
resolver
set
up
that
it's
gonna
contain
the
all
the
accounts
that
are
part
of
the
current
cluster
you
you
can
also.
A
This
is
a
static
version
of
the
accounts,
but
you
can
also
you
also
have
the
alternative
of
making
this
url
resolver
so
that
you
can
have
a
nuts
account
server,
be
enabled
the
one
that
hosts
all
these
accounts
these
and
serve
them
through
http.
In
this
case,
it's
simple
enough
to
just
use
the
memory
resolver.
A
And
we'll
create
a
user
for
the
credentials.
Provisioner
in
this
case
called
the
chat
access
using
the
signing
key
then
that
we
created
previously.
So
in
this
case
it's
gonna
be
adding
nc,
nsc,
add
user.
All
of
this
happening
within
the
kubecon
account
and
then
we're
gonna
run
the
provisioner
that
is
going
to
be
using
the
kubecon
account
jwt,
then
the
signing
key
to
create
users
and
then
its
own
credentials
to
be
able
to
connect
to.
A
So,
in
terms
of
the
next
client
code
it
this
is
going
to
be
represented
by
a
q
subscription,
so
you
can
have
multiple
of
these,
and
all
of
them
will
be
load
balanced
and
also
in
case
you
have
a
super
cluster
that
is
with
gateway
connections.
Then
the
one
that
is
closest
to
you
is
the
one
that's
going
to
be
receiving
the
request,
and
only
when
that
all
the
subscriptions
that
are
local
to
you
fail
then
and
externally,
within
another
cluster,
subscriber
and
well
q.
A
Instead,
so
this
is
the
credentials
probationer
now
for
to
request
access.
This
is
going
to
be
a
simple
nats
request,
but
we
do
need
permissions
to
make
that
request
in
this
case
we're
going
to
create
another
user
in
this
case
we're
calling
it
the
chat,
credentials,
request
user-
and
this
can
be.
These
are
credentials
that
can
be
shared.
A
So
this
is
only
you
can
do
this.
Every
is
the
most
that
you
can
do
with
this
service
is
request
access,
so
we
create
this
new
credenti,
this
new
user
for
credit
credentials,
making
sure
that
you
are
able
to
make
subscriptions
on
inbox
inbox
is
a
special
subject
used
for
receiving
requests
within
the
same
cluster.
In
case
we
have
a
cluster
of
clusters.
There
is
gonna,
be
and
changing
between
accounts,
this
inbox
prefix
changes.
It
should
be
underscore
r
underscore
greater
than
so.
A
With
that
we
now
we
have
a
user
for
making
requests
and,
for
example,
we
so
we
already
have
the
credentials
provisional
running.
We
make
a
request
to
get
access
and
then
the
pro
the
credentials
provisioner
is
going
to
be
replying
back
with
this
jwt
back
and
not
as,
along
with
a
private
key
that
we
can
use.
A
It
was
for
each
one
of
these
users,
a
public
key
pair
was
generated,
so
the
the
private
key
was
shared
to
us
and
the
public
and
public
end
key
is
part
of
the
jwt
so
and
is
represented
here
and
the
it
is.
The
user
is
named
foo
in
this
case,
but
it's
better
represented
by
the
public
and
key
that
belongs
to
this
jwt
and
this
public
end
key.
A
A
A
The
nets
configuration
this
is
the
memory
resolver.
We
have
a
few
accounts.
This
is
the
kubecon
account
that
represents
everything.
That
was
all
the
users,
but
it
doesn't
have
any
notion
about
the
which
users
have
been
created.
It
only
has
knows
that
there
is
an
account
that
has
a
public
end,
key
assigning
key
okay,
so
we'll
start
the
server.
A
A
A
A
So
that's
it
for
my
talk
and
thank
you
for
attending
the
talk
so
I'll
try
to
go
one
by
one
over
the
questions.
I
I
see
some
coming
so
one
from
sebastian.
If
you
have
a
test
and
production
environment
with
a
kubernetes
cluster
in
each
of
them,
would
you
recommend
to
separate
nuts
clusters
in
each
environment
or
one
that's
clustered
in
both?
So
you
have
a
test
and
production
environments.
A
Okay,
sorry,
my
video
was
off
okay,
so
so
yeah
we're.
We
have
the
two
different
kubernetes
clusters
and
we
I
mean
depends
on
whether
we
want
to
I
mean
it
is
definitely
possible
to
create,
like
a
large
super
cluster,
with
multiple
kubernetes
and
connect
the
production
one
to
test.
But
in
this
case
I
I
would
just
keep
them
separate
because
they're
test
and
production,
but
there
is
it's
totally
fine-
to
have
a
use.
A
In
terms
of
the
application
level
yeah
I
mean
it
is
fine
to
have
the
same
nats
cluster
and
then
use
accounts,
for
example,
to
separate
the
applications
that
are
running
with
the
test
version
of
the
applications.
So
you
can
have
an
accounts
or
namespace
for
the
test
applications
and
then
another
one
for
the
production
applications,
and
then
you
can
even
use
some
of
the
permissioning
from
the
queue
groups.
So
you
can
have
an
example,
a
queue
subscription
that
is
registered
to
the
production
group
and
it
is
using
the
same
the
same
name.
A
So
application
is
the
same,
but
you
can
have
this
application
that
subscribes
to
foo,
using
the
queue
group
production
and
then
the
other
one
is
using
the
q
group
test
and
then
you
can
that
way,
you
can
more
finally
scope
with
what
applications
can
to
which
topics
applications
can
send
topics
so,
okay,
so
for
the
application
one
single
nut
server.
I
think
it's
fine.
Yes,
it's
fine.
A
A
A
So
then
they
will
try
to
connect
to
at
least
one
have
at
least
one
connection
to
a
member.
From
the
other
cluster-
and
they
will
figure
out
that
the
routing
is
properly
there's
some
gossiping
as
well,
so
that
it
is
important
to
always
use
the
public
ips
that
you
want,
then
advertise
otherwise,
accidentally,
you
could
have
internal
ips
be
advertised
to
the
nodes
that
were
meant
for
external
access,
but
but
yes,
so
that's
one
option
to
use
nuts
gateways
depending
on
the
requirements.
You
could
also
use
a
leaf
nodes
leaf.
A
A
Connectivity,
this
super
cluster,
and
that
would
be
another
way
to
get
a
multi-region
without
having
the
applications
themselves
connect
to
using
the
gateway
connections
to
all
the
other
nodes.
So
you
can
start
you
start
with
gateway
connections
or
if
you
already
have
a
super
cluster
use.
Lyft
node
connections
for
the
multi-region
connectivity.
A
Yeah
I'll
wait
for
a
couple
of
so
yeah.
There's
a
also
gave
another
tutorial
session
where
you
can
see.
Some
of
these
concepts
live,
and
you
can
definitely
check
out
the
the
code
on
the
kubecon
2020
repo
that
I
shared,
so
you
can
play
with
the
chat,
application
and
maybe
inspect
the
traffic
and
use
the
system
accounts
to
be
able
to
monitor
how
the
events
are
flying
by.