►
From YouTube: Modern Service Networking With Consul Connect, Envoy and Kubernetes - Nic Jackson, HashiCorp
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
Modern Service Networking With Consul Connect, Envoy and Kubernetes - Nic Jackson, HashiCorp
A service mesh is necessary for organizations adopting microservices and dynamic cloud-based infrastructure. Traditional host-based network security must be replaced with modern service-based security to accommodate the highly dynamic nature of modern runtime environments. In this talk, we will look at Connect a significant new feature in the open source Consul from HashiCorp. Connect provides secure service-to-service communication with automatic TLS encryption and identity-based authorization. We will cover both the theory why a Service Mesh enhances your application security, and a deep dive on configuring and operating Connect and Envoy to secure your Kubernetes services.
To learn more click here: https://sched.co/FuKY
A
So
today,
I
want
to
talk
to
you
about
modern
service.
Networking
I
want
to
talk
to
you
about
a
new
feature
of
consult,
called
connect
and
I
want
to
talk
to
you
about
how
you
can
use
it
with
kubernetes
and
how
we
can
use
envoy
super-easy,
so
I
work
as
a
developer
advocate
at
Hoshi
caught
and
I've
worked
in
the
industry
for
like
over
20
years
now.
I
do
quite
a
lot
of
gray
hair
and
the
key
thing
that
I've
always
struggled
with
I've
always
had
a
problem
with
when
I
been
building
systems.
A
A
A
So
I
really
like
this
quote
from
from
the
sim
attacking
security
report,
and
it's
that
you
know
one
of
the
key
phases
in
most
targeted
attacks
is
what's
known
as
lateral
movement.
Attackers
rarely
look
out
and
manage
to
compromise
the
computer,
and
this
is
kind
of
the
key
thing
right
that
once
you've
compromised
that
perimeter
firewall.
A
This
is
when
an
attacker
can
run
amok
in
your
network.
This
is
when
they're
going
to
be
starting
to
look
around
and
try
to
do
the
real
damage.
They're,
not
necessarily
gonna,
be
stealing
all
of
your
data
from
the
first
service.
They
hit
simple
example:
how
does
that
work?
Well,
as
an
attacker
I've
identified
that
you've
got
a
service
and
it's
a
front-end
service
for
your
e-commerce
website.
A
It's
a
favorite
service.
It
doesn't
have
any
real
data,
but
what
I've
identified
is
there's
a
vulnerability
in
this
application.
It's
no
js'
there's
a
framework
vulnerability
which
allows
me
to
do
remote
code
execution
from
that
remote
code.
Execution
I
can
execute
operating
system
commands
on
the
underlying
container
because
well
the
containers
not
secure
either,
but
the
key
thing
is
that
that's
not
my
destination,
like
I,
can't
really
get
anything
out
of
that
service.
But
what
I'm
starting
to
do
is
I'm,
going
to
start
to
look
to
move.
A
A
You've
got
authorization
between
those
two
services
except
you're,
not
using
the
transport
level
encryption.
So
I've
got
in
to
your
network
I've
snooped
around
I've
identified
two
services
which
I
should
have
no
permission
to
be
able
to
interact
with
and
I've
retrieved
your
admin
token
and
the
payload
that
that's
all
I
need
to
be
able
to
execute
a
further
attack
inside
your
system.
A
You
know
that
in
itself
is,
is
a
sort
of
it's
like
an
e-commerce
example
right,
but
the
key
thing
is
around
a
lot
of
the
the
recent
sort
of
exposure.
It's
not
so
much
about
financial
losses
about
data,
so
we
really
do
have
to
be
thinking
deeper
than
that
perimeter
firewall
when
we're
sort
of
looking
in
network
security.
A
So
the
two
problems,
so
the
two
problems
that
we
had
in
this
previous
attack,
which
is
not
so
uncommon,
right,
open
network
access,
I
had
absolute
freedom
of
movement
right.
The
way
through
your
network,
one
side
bypass
a
permit
firewall
mistake
number
two:
you
assume
that,
because
that
perimeter
firewall
exists,
that
you
don't
need
TLS
internally,
you
know
you
terminate
TLS
between
the
client
and
the
Gateway,
the
endpoint,
but
internally
hey
the
firewalls
good
I,
don't
need
TLS,
you
do
need
TLS.
A
So,
let's
address
those
so
open
network
access,
so
you
know
that
this
kind
of
traditional
approach
who
around
just
having
a
perimeter
firewall
this
this
kind
of
what
what's
often
commonly
known
as
a
castle
and
moat
approach.
This
is
not
a
new
problem.
This
is
a
problem
which
was
solved
a
long
long
time
ago.
It
was
solved
with
problems
around
realizing
that
you
need
network
isolation,
that
the
second
that
you
can't
protect
your
infrastructure
with
with
physical
security
with
full
walls,
then
you
need
to
be
thinking
about.
How
do
you
separate
the
responsibilities?
A
How
do
you
separate
the
traffic
inside
to
avoid
these
lateral
movements
and
network
segmentation
is
a
solution
to
that
again?
This
is
like
a
30
year
old
solution.
This
was
the
solution.
It
was
invented
probably
shortly
after
the
network
itself,
but
what's
network
segments
does?
Is
it
kind
of
states,
let's
break
up
the
network,
let's
break
it
up
into
areas
of
risk
or
areas
of
trust,
so
let's,
for
example,
break
it
up
into
front-end
services
and
back-end
services
now
moving
deeper
than
that,
we're
now
working
in
a
multi-tenant
environment.
A
So
you
know,
you've
got
multiple
applications
running
on
a
single
node.
You've
got
multiple
containers
running
on
a
single
kubernetes
node,
and
we
need
to
kind
of
go
deeper
than
just
network
level
segmentation
and
we
need
to
start
thinking
about
service
level
segmentation
because,
potentially
those
areas
of
risk,
those
areas
of
trust,
are
now
mixed
into
the
same
node.
A
A
So
how
do
we
deal
with
this?
So
we've
got
two
problems.
One
is
that
the
the
application
deployment
is
disconnected
from
the
network
configuration
what
I
mean
so
I
mean
that
you
know
the
applications
are
not
being
orchestrated
by
you
directly
they're
being
orchestrated
by
a
machine,
but
then
how
do
you
manage
that
in
terms
of
controlling
firewall
routing?
How
do
you
control
things
like
you
know,
sort
of
routing
tables
and
stuff
like
that?
It's
not
an
easy
problem,
because
what
we
want
to
do
is
we
want
to
be
able
to
do
this.
A
We
want
to
be
able
to
state
that
service
a
can,
only
talk
to
service
B,
so
in
in
the
kind
of
this
old
network
segmentation
mode,
I'm
gonna
configure
my
routing
rules
to
only
allow
those
to
service
a
instances
12
and
10.
To
talk
to
my
service
B
instance,
one
potentially
also
add
some
firewall
pause
in
the
dynamic
environment
that
changes
all
the
time
it
changes
without
me
knowing
it.
A
A
Add
another
layer
of
complexity
kubernetes,
our
schedulers,
we
don't
even
know
potentially
which
node
an
application
is
running
on
the
application,
is
gonna,
be
spread
across
a
number
of
nodes,
and
that
makes
configuring
those
routing
rules
even
more
difficult.
The
more
application
instances
you've
got
the
more
difficult
those
routing
rules
are.
So
what
you
end
up
doing
and
I
don't
blame
anybody.
Is
you
end
up
sort
of
segmenting
your
networks,
but
allowing
entire
subnets
for
your
cluster
and,
as
we
kind
of
saw,
that's
that
can
be
a
big
risk.
A
What
we
want
to
be
able
to
do
is
have
a
dynamic
model
for
network
segregation.
We
don't
want
to
be
defining
things
on
static
network
locations.
We
want
to
be
basing
things
on
application
ID.
So
we
want
to
take
an
intention
based
I
have
the
intention
that
application
a
talks
to
application
B,
it's
it's
simpler
and
it's
dynamic
because,
as
the
applications
are
rescheduled,
you
don't
need
to
keep
reconfiguring
those
rules.
A
So
a
second
problem
TLS.
What
about
our
TLS
so
kind
of
one
of
the
key
things
in
in
this
sort
of
an
attack
is
with
that
lateral
movement.
The
ability
to
read
data
off
the
wire
is
really
really
dangerous.
Right
I
mean
there's
two
things
as
an
attacker
when
I
get
inside
your
system,
I
can
go
straight
for
your
database.
I
can
try
and
sort
of
attack
the
the
database
inside
the
store,
but
if
you're
not
using
encryption
on
your
transport,
I,
don't
even
need
to
I
can
just
read
the
data
straight
off
the
wire.
A
Does
that
take
longer
yes
takes
longer.
Is
that
a
problem?
Well,
maybe
not
because
Oh,
wasp
or
wasp
stated
that
it
can
take
up
to
a
hundred
and
eighty
days
before
you
detect
a
breach.
So
that
means
that
somebody
can
be
in
your
system
snooping
around
reading
your
data
for
180
days
before
you,
you
notice
it,
and
if
you
look
at
sort
of
a
recent
attack
on
a
British
airline,
there
was
something
like
forty
days
before
they
noticed,
and
this
was
a
like
a
public
script
right.
A
You
know
there
was
a
public
script
on
their
website
that
they
didn't
realize
what
it
was.
There
was
harvesting
data
for
forty
days,
so
imagine
that
when
it's
hidden
deep
inside
your
system,
I
think
hundred-
and
you
know
so-
why
don't
we
use
TLS
internally?
Well,
so,
if
anybody's
ever
tried
to
implement
TLS
internally
service
a
service
not
using
internal
load,
balancers,
it's
difficult.
You've
got
to
manage
things
like
certificate
authority.
A
You've
got
to
do
things
like
distributing
keys
and
certificates
to
to
be
able
to
terminate
TLS
you've
potentially
got
to
be
able
to
change
your
code
on
your
application
to
be
able
to
to
reconfigure
the
the
endpoints
for
for
TLS,
as
opposed
to
just
plain,
and
all
of
these
things
are
kind
of
challenging,
but
they
don't
need
to
be
because
I'm,
not
the
bringer
of
doom.
What
I
want
to
talked
about
is
the
easy
option
and
that's
the
service
match.
A
You
know,
there's
been
a
lot
discussed
about
service
mashes
I
mean
I.
Think
coop
con
last
year,
over
in
in
the
US,
was
the
first
time
when
there
was
a
huge
number
of
talks.
There's
a
lot
of
interest
and
there's
a
lot
of
interest
because
they
solve
really
difficult
problems
in
a
very
elegant
way,
so
they
work
predominantly
because
you
end
up
with
these
two
layers.
You
have
your
control
plane,
which
is
you
centralizing,
distributed
highly
available
control
plane
and
you
have
the
data
plane,
so
you
control
plane.
A
This
is
like
your
Ezio
console,
connect
data,
plane,
again
sort
of
envoy,
probably
the
most
popular
data
plane
at
the
moment.
It's
one
that
most
of
the
service
you
seem
to
be
adopting,
and
these
two
components
work
together
to
be
able
to
provide
the
functionality
that
we
need
to
gain
this
security,
so
the
control
plane.
A
Catalog
you've
got
to
have
the
ability
to
understand
which
services
exist
and
where
they
are,
you
don't
die.
A
user
need
to
know
where
they
are,
but
the
control
plane
needs
that
information
and
kind.
Of
importantly,
it
needs
the
ability
to
manage
a
certificate
authority
and
it
needs
the
ability
to
be
able
to
generate
the
x.509
certificates
which
are
needed
to
secure
the
TLS
endpoints.
A
A
You
know,
I
still
think
you
need
to
augment
your
services
with
with
certain
observability
metrics.
But
you
know
the
service
match,
gives
you
a
lot
of
stuff.
Out-Of-The-Box
history,
fat,
client,
stuff,
like
I've,
stood
and
I've,
talked
about
the
need
for
building
reliable
applications.
The
need
that
you've
got
to
embed
into
your
code.
Things
like
circuit
breaking
timeouts.
You
know
configuration
around
load,
balancing
retry
logic,
but
that
takes
effort.
That's
hard.
That
requires
language
dependencies.
A
Even
Netflix
themself
said
that
history,
as
a
library
was
one
of
the
kind
of
the
kind
of
you
know
something
they
didn't
like.
It
was
a
dependency
in
which
every
micro
service
had
and
which
is
something.
That's
in
some
ways
broke
that
micro
service
pattern,
but
the
data
plane
can
handle
all
of
that.
For
you,
it
allows
your
application
to
be
somewhat
Network
agnostic
to
be
done,
and
that's
a
good
thing,
because
you've
got
then
a
centralized
capability
for
that
that
information.
A
So
how
do
you
deploy
it?
So
do
I
need
to
reconfigure
my
application.
Is
there
going
to
be
a
huge
amount
of
recoding
that
I
need
to
do
and
the
answer's?
No,
because
we
leverage
patterns
like
sidecars,
so
we
we
leverage
a
pattern
where
we're
injecting
the
data
plane,
injecting
the
Envoy
proxy
into
an
isolated
environment
like
a
pod
with
our
application.
So
in
our
pod
our
application
binds
localhost.
It
is
absolutely
not
accessible
from
any
of
the
service
externally.
It
can
only
be
accessed
from
envoy.
A
Now
envoy
is
exposing
the
the
sort
of
the
ingress
into
the
application.
So
all
traffic
is
gonna
flow
through
envoy
and
then
into
your
application,
and
by
that
you
don't
need
to
change
any
application
code
in
order
to
to
do
things
like
services,
service,
authentication
or
implementing
TLS,
because
envoy
is
terminating.
All
of
that,
for
you,
it's
managing
it.
For
you.
A
A
So
it's
been
hugely
successful.
There
are
like
millions
and
millions
of
downloads,
and
there
are
some
absolutely
massive
clusters
in
excess
of
twenty
thousand
nodes
of
console.
A
lot
of
people
will
rely
on
it
on
a
day-to-day
basis
for
not
just
running
modern
applications
and
schedulers
like
nomads
and
kubernetes,
but
also
for
running
sort
of
more
legacy.
Applications
for
doing
service
discovery
in
in
like
VM
fleets
or
actually
even
on
physical
machines
and
and
the
architecture
of
it
looks,
looks
like
this
in
that
it
is
highly
available
system.
A
So
you
have
a
cluster
of
server
nodes,
so
you're
gonna
run
a
quorum,
you're
gonna
have
three
or
five
or
seven,
and
these
are
going
to
be
running
inside
of
kubernetes
and
the
way
this
works
is
that
console
has
the
concept
of
leader
and
a
follower.
So
the
leader
is
the
thing
that
manages
the
consistency.
It's
the
thing
that
ensures
that
you've
got
reliable
replication
of
data
across
all
of
the
cluster.
A
Changing
any
of
your
your
console,
Connect
intentions,
they
get
forwarded
to
the
server
and
the
server
is
only
gonna
write,
those
to
the
RAF
log
when
it's
received
a
quorum
of
responses
from
the
followers,
so
it
makes
it
very
highly
available,
but
highly
consistent
when
you're
interacting
with
console
you
don't
talk
directly
to
the
server
and
the
the
reason
that
you
don't
do.
That
is
because
we
want
to
make
this
thing
performant.
It
has
to
be
highly
distributed.
A
So
a
lot
of
the
capabilities
in
terms
of
things
like
caching
of
service
catalogs,
the
ability
to
to
do
all
of
the
health
checks
they're
done
by
the
clients.
So
you
don't
need
to
load
balanced,
a
console
server,
because
all
you
do
is
talk
to
the
client.
The
client
is
a
hundred
percent
aware
of
the
state
of
the
cluster,
where
the
leaders
are
where
the
the
followers
are.
A
If
there
are
any
unhealthy
cluster
server
nodes,
it
has
got
built-in
capabilities
around
retries,
so
that
makes
it
again
operationally
simple
and
very,
very
reliable
when
you're
building
that
out
into
kubernetes.
You
end
up
with
something
like
this,
so
you
you
end
up
with
your
your
quorum
of
console
servers.
They're
gonna
be
running
on
your
your
kubernetes
nodes.
Somewhere,
it
doesn't
matter,
you
know,
that's
the
beauty
of
the
modern
scheduler,
but
on
each
of
the
nodes
inside
of
like
is
something
like
a
daemon
set
you're
going
to
be
running
each
console
client.
A
A
This
is
using
the
the
swim
protocol,
which
a
lot
of
distributed
systems
are
going
to
use
and
I'm
I'm
kind
of
proud
to
say
that
Hoshi
Corp
research
have
published
a
paper
on
some
enhancements
to
to
the
swim
protocol,
to
make
it
more
more
reliable,
which
of
course,
is
implemented
and
consoled,
but
is
also
open
sourced
so
that
other
people
can
implement
it.
If
they're
using
swim
as
well.
A
So
RCA,
we
still
have
our
certificate
authority
and
I
mentioned
inside
of
the
control
plane.
One
of
its
responsibilities
is
managing
that
certificate
authority.
So
in
console
connect
you
have
the
built
in
certificate
authority
now,
but
that's
gonna
serve
all
of
the
purposes
around
generating
allowing
you
to
rotate
your
route
certificate.
Sleep
certificate
signing
request,
but
in
addition
to
using
the
built
in
CA,
you've
also
got
the
capability
to
leverage
hash
called
fault.
A
So
if
you're
already
using
vault
and
you're
using
vault
for
your
PKI
infrastructure,
or
maybe
you
need
the
capability
to
use
an
HSM
for
enhance
security,
then
you
know
that
there's
an
optional
and
pluggable
vault
integration
as
well
and
to
connect
so
kind
of
just
a
quick
overview
of
how
it
works
is
that
you're
gonna
generate
the
clients.
Gonna
generate
the
key
pair.
It
sends
that
request
to
the
connect
server
for
signing
and
potentially
the
confusing
vault
it'll
forward
it
on.
But
then
that's
gonna
sign
your
your
your
certificate.
A
A
But
one
of
the
things
that
you
want
again
around
certificates
is
rotation
and
that's
important
stale
TLS
certificates,
long-lived
certificates.
You
want
to
try
and
keep
TT
ELLs
on
things
as
short
as
possible.
One
of
the
nice
features
of
Connect
is
that
it
allows
you
to
do
root
level
rotation
on
your
certificates
and
the
way
that
that
works
is
in
the
traditional
flow,
where
you
have
a
route
an
intermediary
in
the
leaf
which
would
be
given
out
to
the
service
when
you
want
to
rotate
a
route.
A
A
So
we've
got
this
capability
of
having
this
uninterrupted
seamless
ability
to
rotate
root
certificates
because
of
using
this
cross
signing
because
the
intermediary
is
going
to
be
valid
against
both
so
intentions
like
what's
simpler
than
that,
you
know
the
the
capability
to
just
say:
I
want
to
allow
this
communication
between
server
to
services
by
using
the
service
name.
I
want
the
ability
to
deny
the
communication
between
these
two
services
and
we'll
see
this
a
little
bit
more
in
depth
when
I
do
a
little
demo,
hopefully
envoy
right,
it's
the
obvious
choice.
A
A
So
kind
of
how
lack
just
quickly
how
this
all
ties
together
then,
is
that
the
way
that
it
works
is
that
when
envoy
is
starts,
it's
gonna
get
bootstrapped
and
then,
when
it
sort
of
starts
up
its
going
to
connect
to
the
console
client,
it's
going
to
obtain
its
certificates
and
the
keys
that
it
needs
to
be
able
to
to
secure
the
endpoint
with
mutual
TLS.
So
it
does
that
because
what
we've
done
is
we've
implemented
the
ax
D
s,
the
Envoy
XDS
API
inside
of
console.
A
A
We've
got
to
think
about
updates.
We've
already
mentioned
that
we
want
to
be
able
to
rotate
certificates.
We
want
seamless
updates
to
our
our
system
and
we're
gonna
do
that
in
a
very
sort
of
low
overhead
way,
because
the
client
is
issuing
a
blocking
query
on
console,
which
means
that
it's
kind
of
saying
when
you
get
some
updates
on
ax,
let
me
know,
and
that's
a
really
low
overhead-
it's
not
polling.
It
just
maintains
that
and
envoys
doing
the
same
thing,
because
we've
got
that
persistent
G
RPC
connection
between
the
client
and
envoy.
A
In
terms
of
when
you
get
that
connection,
so
the
clients
can
initialize
connection,
they
can
do
a
little
bit
of
the
TLS
handshake
envoy
is
gonna
request
that
the
client
sends
its
client
certificate.
It's
part
of
the
MT
LS
flow
so
that
client
certificate
has
got
that
x.509,
spiffy
identity,
encoded
into
it
inside
the
URI
Sun,
and
only
if
the
you
know
the
the
the
certificate
is
signed
by
the
right.
The
right
route
then
will
that
connection
be
allowed?
A
Well,
there's
an
additional
step
because
we
want
to
validate
it's
not
just
a
case
of.
Is
this
connection
presenting
valid
identity,
but
it
is
this
service
allowed
in
my
intention
graph.
So
envoys
gonna
make
a
call
again
using
that
XDS
API
to
console
and
it's
gonna
say:
I've
got
a
request
from
service.
A
is
this
okay.
Is
this
allowed
in
the
intention?
Graph
and
console
will
give
a
yes
or
a
no.
A
So
that's
that
that
whole
process
is
not
terribly
inefficient,
because
actually,
what's
happening
is
between
those
two
Envoy
proxies.
You
can
end
up
with
persistent
connections.
You
know
you
want
to
be
able
to
maintain
the
persistent
connection,
so
you
want
to
avoid
having
to
do
the
DM
TLS
handshake,
every
time,
every
request-
and
you
certainly
don't
want
to
be
doing
the
REO
thent
ocation
every
time,
because
that's
gonna
cause
a
centralized
dependency
on
the
control
plane,
but
also
it's
gonna
slow
down
the
application.
So
it's
a
very,
very,
very
low
overhead.
A
So
in
terms
of
how
we
segment
well,
this
was
our
previous
problem
and
we
said
that
the
reality
was
gonna.
Be
this,
but
that's
fine,
because
what
we're
now
doing
is
we're
segmenting
by
using
intention
based
security.
All
of
the
exposed
ports
in
the
system
are
M.
Tls
secured
you've
got
to
have
a
valid
identity
in
order
to
be
able
to
connect
whether
it's
open
or
not.
A
A
And
it
would
be
wonderful
if
everything
was
kubernetes,
but
it
isn't.
Unfortunately,
we
have
to
deal
with
legacy
systems
and
console
Connect
allows
you
to
deal
with
that.
You
can
integrate
console
Connect
as
easily
as
you're
running
it
on
kubernetes,
as
you
can,
with
a
like
a
java-based
application
on
a
Linux
VM
or
even
a
windows-based
application
running
on
a
well
Windows
virtual
machine
and
even
physical
infrastructure
right.
There
is
still
similar
el4
course.
A
You
can
then
use
a
few
databases,
and
if
you
want
to
go
with
the
next
level,
you
don't
even
need
to
to
use
that
the
sort
of
the
configured
data
plane.
If
you
need
super
low
latency,
then
actually
you
can
use
a
software
development
kit.
So
this
is
an
example
of
how
you
can
make
a
direct
G
RPC
connection
using
the
software
development
kit,
and
this
relies
on
no
sort
of
proxy
at
all.
So,
let's
take
a
look,
hopefully.
A
A
A
A
A
The
the
difference
is
that
if
I
want
to
a
naval
console
connect
on
my
cluster
and
to
to
add
that
envoy
data
plane
into
my
pod
I,
don't
have
to
write
anything
special
I,
don't
need
to
define
any
special
containers
or
set
up
any
special
configuration.
I'm
just
gonna
use
the
annotations,
because
console
connect
has
kubernetes
integration
into
it.
That
allows
you
to
just
specify
the
annotation
console,
connect
equals
true
and
then
I
can
specify
my
up
streams,
because
in
the
same
way
that
I'm
only
talking
localhost
inbound
via
my
Envoy
proxy.
A
What
I
want
to
make
a
call
out
to
a
service,
then
I'm
gonna
talk
localhost
as
well.
That's
the
way
that
envoy.
It
means
that
I
don't
need
to
worry
about
the
whole
kind
of
history,
saying
the
circuit
ballad,
breaking
the
low
balancing,
because
envoy
is
performing
that
functionality
for
me,
so
I
tell
envoy
I
want
you
to
connect
to
this
service
and
it'll.
Expose
me
a
local
host
port,
which
makes
my
application
configuration
super
easy
moving
down
there
again,
you
know,
there's
there's
really
nothing,
nothing
special
going
on
nothing
complicated!
A
A
Look
at
our
problems.
Right
TLS
is
hard.
You've
got
to
do
a
whole.
The
CA
thing
you've
got
to
work
out
how
to
distribute
certificates.
You
got
to
work
out
how
to
rotate
keys.
No,
you
don't
use
the
service
match
because
that's
its
job.
It
does
all
of
that
for
you
when
it
comes
to
things
like
configuring,
that
network
segmentation
to
be
able
to
reduce
the
blast
radius
in
the
event
of
a
breach.
A
You
know
you
please
go
and
try
it
out.
Look
the
hound
child
is
super
easy
to
use,
check
out,
console
and
some
more
of
the
documentation
at
console,
dot,
IO
helm
chart
can
be
found
in
our
github
repo
at
github,
comm
Hoshi
corpse
that
console
helm
and
we
are
moving
to
get
as
part
of
the
the
official
helm,
distribution.
I.
Think,
there's
a
PR
open
on
that.
If
you
do
have
any
questions,
I
will
be
outside
and
more
happy
to
to
chattin.
Maybe
I'll
even
finish
my
demo,
but
thank
you
so
much
for
for
listening.