►
From YouTube: Tutorial: Building Secure & Decentralized Global Applications on Kubernetes with... Waldemar Quevedo
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.
Tutorial: Building Secure & Decentralized Global Applications on Kubernetes with NATS - Waldemar Quevedo, Synadia
Learn how to build applications that span across more than one Kubernetes region by using a NATS based global communications network. In this talk, it will be covered how to setup a globally available NATS cluster using multiple Kubernetes regions from 4 different clouds (AWS, Digital Ocean, GKE & Azure) using NATS gateways and leafnode connections, as well as how to create applications that take advantage of the NATS decentralized authorization model by showing how to implement a simple Slack-like clone that runs under your terminal. Attendees of this session will be able to follow through the implementation of the service (and interact with each other!) during the talk, to run the examples it is recommended to have Docker installed.
https://sched.co/Zekp
A
A
You
can
find
me
twitter
as
a
wall
qs,
I'm
a
software
engineer
inside
nadia,
where
many
of
the
maintainers
of
nets
are
working.
I've
been
a
long
time,
snaps
user.
I
wrote
a
book
about
nets
a
couple
of
years
ago
covering
many
of
the
basic
concepts,
some
some
of
the
messaging
patterns
that
you
can
do
with
nets,
and
in
this
talk
this
tutorial
we're
gonna
cover
how
to
set
up
a
decentralized
authorization
scheme
for
a
next
cluster.
A
A
This
is
how
the
net
application
chat.
Application
looks
like
you
can
have
a
number
of
channels,
and
then
users
can
send
messages
to
any
anyone
that
is
member
of
that
channel,
and
you
also
have.
They
also
have
support
for
direct
messages
and
in
case
one
of
those
messages.
Whenever
you
receive
a
message,
you'll
get
a
dot,
basically
telling
you.
A
They
have
a
new
message
in
terms
of
a
nuts
strings
or
subscriptions
this,
how
they
look
like
in
terms
of
the
subjects
that
are
going
to
be
used,
we'll
have
a
subject
named
chat.kubecon.posts
and
is
the
wild
card.
The
asterisk
is
wild
card
so
that,
whenever
you
post
to
kubecon,
that's
gonna
be
represented
by
a
message
that
is
on
the
subject
that
post.kucon
or
for
the
nuts
channel
and
dot
snats
on
general.
A
So
this
there's
going
to
be
a
single
subscriber
part
of
this,
and
that's
a
cluster
that
whenever
you
make
a
request
with
some
payload
in
this
case
the
payload
is
going
to
be
the
username,
but
you
can
make
a
request
to
chat.rec.access
to
get
some
ephemeral
well,
ephemeral,
unique
credentials
for
that
user
and
those
are
going
to
be
generated
on
demand
for
each
one
of
the
users
in
terms
of
the
global
topology.
This
is
how
it's
going
to
look.
A
A
It's
going
to
be
a
q
subscription
so
that
it
can,
you
can
have
multiple
of
them
and
they
will
become
a
load
balance
and
then
the
chat,
client
application
can
be
connected
to
anywhere
from
this
part
of
the
cluster.
So
there
is
there's
again
decentralized.
There
is
no
center.
All
of
this
could
be
running
everywhere.
A
A
A
There
is
a
one
liner
that
will
install
it
for
you.
You
can
peek
at
the
contents
in
case
you're
concerned
of
the
what
well
the
whether
schemes
you
want
to
pick
up
the
contents
basically
or
you
can
just
use
hom
hombre
to
install
it
so
we'll
need
nsc,
and
there
is
a
we'll
use
this
script
in
a
setup
that
is
part
of
the
kubernetes
repo
and
also
all
of
this
is
going
to
be
available
on
another
for
the
kubecon
2020.
A
A
One
of
them
is
that
it's
going
to
create
the
operator
jwt.
That
is
going
to
be
used
like
the
root
of
trust
from
the
whole
cluster,
and
we
also
create
a
system
account
and
a
couple
of
accounts
for
testing
and
one
for
stand.
For
example,
in
case
it
could
be
used.
We're
not
going
to
use
it,
particularly
in
this
tutorial,
but
it's
just
like
a
generic
account,
and
the
operator
generality
is
quite
important,
as
I
mentioned,
is
the
root
of
trust
from
the
from
the
whole
cluster.
A
You
take
a
look
at
the
script.
You
can
also
check
out
how,
when
you
want
to
make
it
expire
and
solo
that
can
be
configured
so
for
the
purposes
of
this
demo,
we're
going
to
need
at
least
three
different
users.
One
is
going
to
be
the
user
for
requesting
credentials
and
there
is
going
to
be
a
user
that
has
very
constrained
permissions.
A
Then
we
will
need
a
credentials
provisioner
that
is
able
to
respond
to
those
requests.
So
those
are
the
service
interactions
and
also
we
need
user
credentials
for
each
one
of
the
users.
These
are
going
to
be
dynamically
generated
and
I'm
going
to
show
how
this
is
done
so,
but
first,
let's
create
a
kubecon
account.
A
Let's
create
a
cubicle
account,
so
all
of
these
users
are
going
to
be
part
of
this
kubecon
account
and
we'll
do
something
special
with
this
account
is,
and
that
is
we're.
Gonna
create
a
signing
key
this
signing
key
is.
It
is
an
extra
key
that
is
gonna
belong
to
this
cubecon
account,
and
it
is
essentially
what
we'll
be
using
to
create
the
new
users
that
are
part
of
this
cluster
by
using
the
dynamic
credentials
provisioner.
A
So,
let's
edit
the
account
using
this
signing
key,
the
signing
key
is
the
one
that
got
that
is
in
the
output.
The
second
one
here
in
the
output,
a
a
means
that
is
a
public
key
s,
means
that
it's
a
private
key.
So
this
is
the
one
that
we
want
to
use
so
now,
let's
edit
the
account
for
kubecon
and
add
another
jdo
signing
key.
So,
let's
inspect
you
can
see
that
have
a
signing
key
now.
A
A
A
So
at
the
core
level,
everything
else
is
still
publish
subscribe,
and
so,
in
order
to
be
able
to
reply
to
requests,
we
need
to
make
requests.
We
also
need
to
make
a
subscription
to
inbox
and
because
there
is
going
to
be
a
super
cluster
that
is
going
to
be
multi-region,
we
also
need
an
extra
level
of
permissions
which
is,
at
the
underscore,
are
or
routed
globally
requests
that
are
routed
globally.
So
we'll
need
these
permissions
and
let's
go
ahead
and
create
the
user.
A
A
A
In
this
case,
we're
gonna
use
a
static
memory
resolver
that
gives
contains
the
jwts
from
each
one
of
the
accounts.
So
the
these,
the
nat
servers,
do
not
have
any
notion
of
the
users
that
are
part
of
the
system,
but
those
need
something
that
at
least
notion
of
which
are
the
accounts
that
are
in
this
part
of
the
cluster,
so
that
under
the
word
sign
and
all
their
signing
keys
and
stuff.
So
in
this
case
we
generate
the
config.
A
A
So
now
we
have
a
mock
responder,
make
another
request,
and
we
can
see
that
there's
a
request
response
interaction
with
these
two.
If
I
try
to
make
another
request
here,
I'm
gonna
get
deny
the
same.
If
I
try
to
subscribe
to
another
subject
is
not
possible,
so
those
are
the
only
things
you
can
do
with
these
credentials,
the
ones
for
the
making
requests
and
the
one
for
provisioning
or
basically
just
responding
to
anything.
That
is
any
message
that
is
sent
to
this
subject.
A
A
A
Then
I'm
going
to
inspect
them
with,
let's
see
you
can
see
that
this,
the
provisioner
created
a
very
also
a
limited
permissions
for
this
user.
So
the
name
is
a
user,
but
it's
better
and
identified
by
the
public
key
that
and
that's
why
we
needed
the
signing
key
to
be
able
to
generate
these
users
using
that
key
pair.
So
we
have
at
this
wall
us
user.
A
A
A
A
A
A
A
A
A
It
works
by
using
those
credentials,
and
it
subscribes
to
a
number
of
streams
you
can
have.
We
can
see
that
there
is
a
stream
for
the
channels
kind
of
posts
up
for
the
dms
and
for
sending
the
events
that
they're
online
and
whenever
we
want
to
publish
something,
we
will,
of
course
send
periodic
events
for
that
we
are
still
online
and
also
in
case.
We
want
to
post
to
one
of
the
channels
we
will
send.
A
So
we're
to
publish
into
this
a
certain
subject
and
in
for
dms
we
need
the
to
have
received
a
previous
heartbeat
so
that
we
can
talk
to
it.
So
we
need
the
because
we
need
to
use
the
public
end
key.
We
need
to
receive
at
least
an
availability
status
from
one
of
the
car
bidding
that
happens
periodically.
A
A
A
We
need
the
firewall
to
be
open
because
we're
going
to
be
using
host
parts
for
the
port,
the
four
to
the
two
and
seven
especially
75
22,
which
is
the
one
for
the
gateway
connections
as
represented
here
by
these,
are
blue,
arrows
arrows
and
we
also
leave
open
the
the
port
for
leaf
nodes,
which
is
another
type
of
connection.
That's
very
interesting
that
allows
you
to
create
at
least
hop
and
stock
topologies.
A
So
essentially,
you
can
use
this
super
super
cluster
later
as
a
way
to
be
able
to
communicate
with
multiple
nuts
clusters
without
them
be
them
being
themselves
becoming
a
cluster.
But
that
can
be
another
tutorial,
but
so
we
leave
those
open
and
we'll
be
using
helm
for
for
the
setup.
So
you
can
officially
support
nuts
charts
nuts
helm
charts
and
I'm
gonna
move
this
to
right
now.
A
A
A
And
we're
using
the
external
ips
to
able
to
create
the
super
cluster.
So
let's
go
ahead
and
create
first,
the
nuts
accounts
it's
going
to
be
a
configuration
map
in
each
one
of
the
clusters
and
we
need
to
generate
the
list
of
gateway
connections,
so
just
create
a
script
to
create
generating
them
from
the
api
server
metadata.
A
So,
let's
use
this
explicit
list
of
gateways
going
over
the
configuration
a
little
bit
we're
using
alpine
just
for
simple,
simple
debugging
and
we'll
open
a
host
port
for
each
one
of
them,
so
that
that
is
done
by
using
this
external
access,
flag,
no
logging,
and
that
affects
performance.
Actually,
we
enable
off
for
the
auth
we're
going
to
use
the
nuts
accounts
configuration
map
that
includes
the
static
configuration
from
the
accounts,
we're
enabling
the
gateway
ports
and
also
for
with
the
explicit
ips
from
amsterdam,
singapore
and
san
francisco.
A
A
You
can
see
that
we
have
a
connectivity
between
the
clusters.
You
can
you
have
a
local
clustering
working
and
also
it
has
created
outbound
gateway
connections,
in
this
case
from
amsterdam
to
towards
san
francisco,
and
let's
confirm,
for
example,
here
we
are
at
amsterdam.
So
let's
make
a
quick
connection
here.
A
A
A
Just
a
quick
example:
I'm
going
to
show
the
system
credentials
just
to
show
how
the
traffic
looks
like
these
are
the
events
that
are
flowing
through
the
system
for
operations
that
can
be
quite
useful.
You
can
see
how
many
gateways
and
the
stats
from
each
one
of
the
server
the
servers
they're
pretty
readable,
and
we
also
have
extensions
to
able
to
ingest
this
data
into
prometheus.
There's
the
surveyor
project.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
So
that's
pretty
much
it
for
the
tutorial
separately.
We
can
cover
how
to
enable
all
of
this
to
use
a
tls
and
also
looking
at
how
lyft
node
connections
can
actually
make
this
gateway
connections
are
more
straightforward
to
set
up.
That
could
also
be
interesting,
but
okay,
I'll
connect,
then
at
the
for
questions
later.
Okay,
so
thank
you.