►
From YouTube: Securing User to Service Access in Kubernetes - Maya Kaczorowski & Maisem Ali, Tailscale
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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.
Securing User to Service Access in Kubernetes - Maya Kaczorowski & Maisem Ali, Tailscale
Kubernetes makes it easy to run and scale your microservices, and Kubernetes automatically assigns the pods running your service an IP address and a DNS name for discovery and routing. Network security concerns for Kubernetes, however, seem to focus on user access to the control plane, using a bastion; or on service-to-service communication within a cluster, using a service mesh. So how should your development team secure access to the internal services you’re running on Kubernetes — is it enough to just use Kubernetes Ingress and a web proxy? In this talk, we’ll focus on the networking and security questions you should consider when exposing Kubernetes services to your users, including authentication and authorization, load balancing, traffic filtering, and encryption. We’ll discuss different options you have for managing access to these services, using Kubernetes Ingress, Kubernetes load balancer objects, service meshes, web proxies, IPsec, and WireGuard. You’ll come away with a better understanding of how to give service access to users, and how these complement other network solutions you might already have in your cluster.
A
A
That's
the
focus
of
this
talk,
so
we'll
look
at
the
security
properties
that
you
likely
want
for
protecting
access
to
these
internal
services
and
we'll
go
over
the
various
options
that
exist
in
and
out
of
kubernetes
for
protecting
this
traffic
and
then
compare
those
so
analyzing
which
options
work
for
the
security
properties
that
you
actually
need.
This
talk
is
geared
or
meant
for
Network
administrators
or
security
teams
using
kubernetes,
with
some
understanding
of
how
kubernetes
works.
So,
let's
jump
in
there
are
many
kinds
of
traffic
that
might
be
going
to
your
kubernetes
cluster.
A
First,
it's
the
traffic
that
you
need
to
get
kubernetes
working
the
traffic
between
the
components
of
kubernetes,
like
from
the
cube
API
server
to
the
control
plane
in
the
control
plane
to
the
cubelet
in
your
work,
your
nodes
or
pod
to
pod
Communications
hilariously
I
gave
a
talk
on
exactly
this
topic
four
years
ago.
Now
at
kubecon
and
I've
forgotten
all
of
it.
But
if
you
want,
you
can
watch
the
talk,
the
traffic
that's
managed
in
kubernetes
and
is
mostly
has
authentication
integrity
and
encryption
again.
A
Watch
the
talk
if
you're
interested
our
second
kind
of
traffic
is
traffic
from
a
service
to
a
service
such
as
from
like
a
front-end
application
to
a
database.
This
can
be
both
intra
or
inter-cluster.
It
might
be
coming
from
another
kubernetes
cluster
if
the
two
applications
are
in
different
trust
domains
or
hosted
on
different
platforms
or
just
managed
by
a
different
team
or
if
you're,
using
like
a
microservice
architecture
and
the
full
app
runs
across
multiple
clusters.
A
This
service
to
service
traffic
is
often
controlled,
monitored
and
secured
using
a
service
mesh
Third
Kind
of
traffic
here
traffic
from
a
user
to
a
kubernetes
control
plane.
For
when
a
member
of
like
your
devops
team
or
info
team,
is
accessing
the
control
plane
to
manage
cluster
configurations,
you
can
hit
the
IP
of
the
cube,
API
server
directly
and
authenticate
to
cubectl,
but
many
folks
secure
this
connection
with
something
like
Sebastian
and
then
lastly,
traffic
from
a
user
to
a
service
that
you're
running
on
kubernetes.
A
So
thinking
of
those
like
four
kinds
of
traffic
that
we
just
talked
about,
you
know
security,
folks
and
those
are
the
typical
Solutions.
We
also
also
also
mention
security.
Folks
worry
a
lot
about
how
to
secure
access
from
a
user
to
the
kubernetes
control
plane,
like
with
good
reason.
You
know
mostly
because
apps
is
in
the
control
plane,
would
give
you
full
control
over
the
cluster.
However,
we're
not
here
to
talk
about
that,
because
there's
so
much
guidance
on
that
topic.
A
But
what
we
are
talking
about
is
that
last
item
there,
a
user
accessing
internal
applications
that
you're
running
on
kubernetes,
because
there's
a
lot
less
guidance
on
how
to
do
that
and
how
to
do
that.
Well,
an
internal
app
that
you're
running
on
your
kubernetes
cluster
is
different.
Depending
on
your
circumstances.
Some
of
the
other
options
listed
here
like
a
service
mesh
or
Bastion
or
a
load
balancer,
might
apply
to
how
you
protect
traffic
from
users
to
internal
services.
A
So
you're
asking
like
do.
I
really
need
guidance
on
this
topic.
Probably
the
kubernetes
docs
unhelpfully
tell
you
that
your
service
may
or
may
not
be
public,
and
also
it
may
or
may
not
be
authenticated
I'm,
not
a
bad
at
the
docs
like
there's
so
many
potential
options
that
you
can
have
here.
So
it's
on
you
to
implement
a
solution
all
right.
So
what
are
some
examples
of
kinds
of
apps
that
you
have
these
internal
apps,
that
users
are
trying
to
access?
A
There's
many
internal
services
that
might
be
in
your
cluster
when
you're
running
a
service
in
kubernetes.
There
are
a
lot
of
other
things
that
you
run
alongside
your
actual
service
that
you
need
to
maintain
and
then
be
able
to
access
anything.
That's
started
by
Cube
system,
so
databases,
monitoring,
logging
and
tracing
other
tools.
Those
should
only
be
accessible
to
your
info
team
and,
if
you're
in
the
kubernetes
dashboard
or
like
the
web
UI,
that's
another
monitoring
service.
That's
only
meant
for
your
info
team.
A
You
might
also
have
some
other
internet
applications
for
your
organization
that
you,
you
know
manage
and
host
on
kubernetes,
just
like
web
apps
for
your
customers.
Maybe
there's
an
easy
way
internally
to
look
at
a
metrics
dashboard
or
look
up
the
employees
in
your
company
in
a
Wiki
of
some
kind,
and
so
do
you
really
need
to
secure
access
to
these
applications?
Well,
probably,
they
might
include
sensitive
information
that
could
be
used
to
learn
your
organizations.
A
A
So,
let's
look
at
some
criteria,
and
these
are
these
are
the
criteria
we
came
up
with
right
when
you're
hosting
an
internal
application.
There
are
several
security
properties
that
you're
going
to
want
the
service
to
have
first
visibility.
This
is
hopefully
self-evident,
but
if
you're
hosting
an
internal
application,
it
should
well
actually
be
internal.
You
want
something:
that's
not
publicly
accessible
and
restricted
to
a
set
of
individuals
who
are
part
of
your
organization
authentication.
This
ensures
that
you
know
and
verify
the
source
and
destination
of
the
traffic.
A
That
is,
you
verify
the
user
and
the
service
they're
connecting
to
authorization
stricter
than
just
visibility.
Authorization
ensures
not
only
that
your
service
is
internal,
but
only
the
right
individuals
in
your
organization
have
access
to
it.
You
could
also
build
authorization
into
each
of
your
applications
rather
than
as
part
of
the
Central
Access
solution,
but
that's
putting
a
lot
of
a
lot
of
work
on
each
of
your
application
teams.
A
Encryption
by
encrypting
your
traffic
you're,
preventing
just
anyone
from
reading
it
encryption,
ensures
that
only
the
authorized
parties
can
actually
read
the
traffic
so
that
any
unauthorized
party
that
intercepts
traffic
can't
read
its
contents
load
balancing.
If
you're
running
multiple
instances
of
a
service,
you
want
to
load
balance
between
them
so
that
you're
not
overwhelming
a
service
in
any
one.
Node
This
falls
into
the
availability,
part
of
security
and
traffic
filtering.
Your
service
might
not
allow
all
traffic
to
access
it.
A
You
can
fill
the
traffic
for
unusually
high
requests
like
in
response
to
a
DDOS
attack
or
to
rate
limit
one
user
who
might
be
limiting
another
user's
ability
to
use
a
service.
Internal
applications
might
also
filter
traffic
based
on
other
criteria
like
location.
Maybe
you
don't
have
any
employees
in
Australia,
and
so
it's
weird
to
see
traffic
coming
from
there
and,
lastly
auditability
you
want
to
Monitor
and
log
information
about
the
traffic
going
to
your
service,
so
you
can
ensure
it's
acting
as
expected.
A
You
also
need
these
logs
in
case
you
need
to
review
access
as
part
of
like
a
security
incident,
and
there
are
other
criteria
here
that
we
haven't
mentioned,
that
aren't
necessarily
you
know.
Purely
security
focused
you're,
going
to
you're
going
to
want
to
have
for
users
connecting
to
internal
Services,
namely
latency
and
availability,
but,
like
I,
said
we're
going
to
focus
on
the
security
properties.
A
So
let's
keep
these
criteria
in
mind
when
evaluating
solutions
for
accessing
internal
apps,
all
right.
So
what
options
do
we
really
have?
The
first
couple
options
laid
out
on
this
on
this
slide
are
kubernetes
constructs
they're?
What
kubernetes
provides
out
of
the
box
with
cluster
IP
and
then
on
top
of
cluster
IP?
You
can
use
a
kubernetes
load
balancer,
which
allows
you
to
load
balance
traffic,
hitting
a
service
across
multiple
different
instances
of
that
service.
A
Three,
where
the
underlying
network
is
encrypted
or
untrusted.
The
first
is
ipsec,
which
is
a
protocol
for
encrypting
Communications
between
endpoints
and
then
wireguard,
which
is
a
more
modern
tunneling
protocol
for
end-to-end,
encrypted
connections
and
those
can
be
used
Standalone
or
as
part
of
VPN
type
Solutions.
A
B
Thank
you
Maya.
So,
let's
dig
in
so
as
I
mentioned,
the
basic
building
block
for
services
on
kubernetes
is
a
cluster
IP
service
right,
which
basically
provides
a
stable,
IP
and
DNA
stands
for
accessing
Bots
within
a
cluster.
The
virtual
IP
is
shared
among
the
pods.
A
all
the
traffic
router
to
that
ipe
will
be
routed
by
the
cluster
to
that
pod
or
to
any
of
the
replicas
the
Pod.
B
If
the
pods
go
come
in
or
are
scaled
up
or
scaled
down,
though
those
pods
get
removed
from
the
service
destinations,
the
traffic
keeps
working.
Fine,
you
don't
ex.
You
shouldn't
see
hiccups
with
that
point,
however.
The
cluster
IP
service
is
internal
only
to
the
cluster.
It
is
not
something
that
you
can
hit
from
outside
the
cluster
without
doing
some
additional
steps.
B
B
B
B
The
problem
is
that
that
IP
is
public,
which
really
means
that
anyone
on
the
internet
can
reach
it.
So
it
puts
even
more
onus
on
this
application
layer
to
add
authentication
and
authorization
and
to
do
traffic
filtering
a
lot
of
sases
actually
do
something
similar,
not
necessarily
in
kubernetes,
but
they
have
IP
allow
listing,
and
so
that
you
can
only
restrict
access
or
you
can
only
access
the
service
for
using
some
well-trusted
IPS.
B
It
also
allows
you
to
do
traffic
routing
based
on
paths
not
just
host
names.
Some
of
the
some
Ingress
controllers,
like
nginx
and
traffic,
provide
authentication
and
authorization
using
oauth
and
jots,
but
it's
still
really,
and
the
really
nice
thing
that
they
provide,
is
GEOS
encryption,
which
is
that
any
traffic
hitting
your
hitting
that
service
will
get
automatically
get
a
HTTP,
assert
or
and
make
sure
that
those
that
no
one
in
on
the
public
internet
can
intercept
your
traffic
and
see
what
is
going
on
without
doing
like.
B
No
one
can
man
in
the
middle
of
your
thing,
the
fourth
type
of
thing
that
we
use
for
all
of
this
is
kubernetes
Network
policy.
What
this
does
is
that
it
says
for
a
set
of
PODS
or
a
set
of
or
namespace
or
set
of
services.
It
can
restrict
what
traffic
goes
in
and
out
of
that
pod.
So
you
could
say
that
only
a
namespace
can
talk
within
itself.
B
You
can
use
the
network
policy
in
addition
to
like
kubernetes,
load,
balancers
or
kubernetes
Ingress
to
further
restrict
who
can
access
it.
But
really
all
this
provides
is
a
way
for
you
to
secure
servers
to
service
communication.
It
really
doesn't
help
much
with
the
user
to
service
communication,
because
the
user
users
are
on
the
public,
internet
and
they're
going
to
be
reaching
over
the
public
internet.
B
The
other
really
interesting
thing:
development
that
happened
in
kubernetes
or
in
this
space
was
a
service
mesh.
What
this
does
is
that
in
typically
in
kubernetes,
when
you
have
pods
communicating
with
each
other,
the
traffic
is
Flowing
between
them
is
plain
text.
It
is
not
encrypted.
It
is
not
some
it
does.
When
you're
sending
traffic
to
someone
on
in
your
network
in
your
cluster,
it
is
not
necessarily
you're,
not
always,
there's
no
way
to
guarantee
who
that
traffic
is
coming
from.
B
B
That
side
of
car
proxy
will
intercept
all
of
the
traffic
and
make
sure,
and
it
will
commit
when
it's
communicating
with
other
services.
It
will
form
mtls
connections
or
Mutual
Tios
connection
and
make
sure
that
the
communication
between
the
services
is
strongly
authenticated,
and
you
know
that
two
services
are
really
that
when
you're
talking
to
a
service
you're
guaranteed
that
it
is
that
service
that
you're
talking
to
and
you're,
also
guaranteed
that
the
person
who's
calling
you
is
the
or
the
service
that
is
calling.
You
is
that
service.
B
A
Back
over
to
me,
so
the
next
option
we
have
is
the
Bastion,
so
Bastion
host
is
a
server
running
an
application
like
a
proxy
or
a
load
balancer
that
serves
as
the
entry
point
to
an
internal
service.
Traditionally,
the
combastian
is
the
point
of
entry
to
your
network.
It's
the
it's
the
hole
in
your
firewall
and
following
a
traditional
Network
model,
because
it
was
a
single
point
of
entry
to
everything
in
your
network
and
everything
inside
of
your
network
wasn't
encrypted
or
authenticated.
A
Since
this
is
before
zero
trust
Trends,
then
the
Bastion
was
particularly
strongly
protected.
So
once
you
got
past
Sebastian,
then
you
were
just
into
the
network,
so
a
Bastion
is
meant
to
be
a
single
bottleneck
for
anything
that
needs
to
flow
into
an
application
and
by
forcing
all
the
traffic
through
a
Bastion,
you
can
then
have
a
single
place
to
enforce
authorization
and
authentication.
Do
any
filtering
you
want
to
do
and
then
log
access.
A
So
it's
your
point
of
entry
yeah,
but
it's
also
your
your
point
of
policy
enforcement.
Typically,
a
Bastion
is
often
just
like
openssh
set
up
on
a
host
U.S
agent
to
the
host
and
then
from
there
you
can
reach
the
resource
that
you're
actually
trying
to
access.
So
in
terms
of
visibility,
Sebastian
has
to
be
publicly
accessible,
which
means
that
others
at
minimum
know
that
it's
there,
even
if
they
can't
actually
access
it.
A
You
can
authenticate
users
to
the
host
on
based
on
SSH,
username
and
password
keys
or
certs,
and
use
this
for
authorization
decisions,
although
you
might
also
be
running
a
Bastion
with
like
a
single
user
that
everybody
logs
in
as
and
so
you
might
not
have
that.
If
that's,
if
that's
what
you've
set
up
instead
opensh
is
encrypted.
So
you
get
that
bastions.
A
Don't
have
any
notion
of
the
services
that
you're
connecting
to
they
just
say
like
oh
you're,
on
the
network
now
you're
in
so
and
then,
and
so
they
don't
try
to
load
balance
or
in
any
way
or
do
any
kind
of
like
sophisticated
traffic
traffic
filtering.
You
know
once
once
you're
in
and
if
you're
using
openssh,
open
SSH
lets
you
log
messages
about
what
the
SSH
server
is
doing.
A
There's
there's
obviously
more
complex
Bastion
offerings
on
the
market
now
which
have
better
logging,
simple
to
manage
authorization
and
some
traffic
management
like
I
mentioned,
but
and
there's
also
hosted
proxies
that
are
provided
by
the
cloud
provider.
So
if
you
have
something
running
in
a
cloud
that
might
be
the
better
solution
for
you
to
have
it
managed
to
manage
for
you
on
your
behalf
all
right.
So
those
are
the
options
that
were
that
we're
considering
that
are,
you
know,
used
for
other
kinds
of
accessing
kubernetes.
A
So
now,
let's
talk
about
kind
of
generic
connection
and
protection
options.
So
ipsec
ipsec
is
a
layer
3
protocol
for
encrypting
information
between
two
endpoints.
It's
used
for
transferring
data
or
as
part
of
a
traditional
VPN
to
encrypt
traffic.
When
it's
on
an
untrusted
Network
ipsec
can
encrypt
the
whole
packet
in
like
a
tunneling
mode
or
just
a
data
packet
in
a
transport
mode
which
allows
you
to
inspect
the
headers
for
like
more
complicated
routing.
You
might
be
wanting
to
do
in
your
network
to
use
ipsec.
A
You
need
to
have
both
the
source
and
destination
host
that
you're,
connecting
from
into
perform
a
key
exchange
to
establish
a
tunnel
of
which
traffic
is
then
sent
so
for
users
that
are
connecting
to
an
internal
service.
That
means
in
practice
that
each
user's
device
will
need
to
be
able
to
initiate
an
ipsec
connection
so,
for
example,
by
installing
a
client
on
each
of
those
users
devices.
A
So
if
we're
looking
at
ipsec
and
IPC
vpns
for
this
use
case
in
terms
of
visibility,
ipsec
doesn't
care
where
it's
connecting
to
as
long
as
they're
reachable.
So
if
you,
if
you,
you,
can
have
a
service
on
only
you
know.
Private
IPS,
but
you'll
need
your
VPN
to
have
something
like
not
traversal
to
actually
make
them
accessible.
A
Ipsec
provides
authentication
and
encryption
of
Ip
packets;
it
doesn't
provide
authorization
natively,
but
probably,
if
you're,
using
an
ipsec
VPN,
that's
exactly
what
it's
doing.
It's
giving
you
authorization
ipsec,
doesn't
have
any
built-in
traffic
management
like
a
notion
of
load,
balancing
or
traffic
filtering,
some
of
my
PSI
vpns.
A
And
lastly,
auditability
again
since
ipsec
is
just
a
protocol,
you
don't
get
any
of
this
for
free,
but
with
an
ipsec
based
VPN,
you
can
expect
to
get
network
logs
of
which
users
are
accessing,
which
services.
In
some
cases,
you
can
also
introspect
the
actual
traffic
like
the
packets
So.
Not
only
would
you
know
metadata,
but
a
connection
like
you
know,
Alice
is
connecting
to
the
hiirs
system,
but
specific
information
like
which
SSH
commands
are
being
run
by
a
specific
user
on
a
specific
box
and
the
last
option
we're
going
to
consider
wireguard.
A
So
if
you're
not
familiar
with
wireguard
wireguard
is
a
layer.
3
tunneling
protocol
that
lets
two
peers
privately
establish
an
end-10
encrypted
connection.
Wireguard
uses
public
Keys
rather
than
public
IP
addresses
to
identify
peers.
So
as
peers
move
connections
can
still
persist,
the
only
thing
you
actually
need
to
configure
is
which
peers
you
want
to
communicate
with
like
ipsec.
A
You
need
to
have
both
the
source
and
destination
host
that
you're
connecting
to
and
from
perform
a
key
handshake
to
establish
a
tunnel
which
is
then
used
for
for
traffic
to
encrypt
the
traffic,
that's
being
sent
so
again
for
users
connecting
to
a
service.
Each
user's
device
will
need
to
install
wireguard.
However,
compared
to
ipsec
wire
guard
is
explicitly
designed
to
optimize
for
security,
performance
and
ease
of
use
and
so
wireguard,
given
it
has
like
opinionated
modern
photography,
there's
very
little
things
to
configure.
A
So
looking
at
wireguard
connecting
to
internal
services,
wireguard
like
ipsec
lets,
you
connect
Two
Hosts
anywhere
as
long
as
they're
reachable
and
can
continue
to
connect,
even
if
an
IP
address
changes
as
I
mentioned.
So
a
user
could
like
initiate
a
connection
to
their
database
on
their
laptop
at
home,
bring
it
to
the
coffee
shop
and
finish
their
work,
and
then
the
connection
will
still
continue
with
no
hiccups.
A
You
can
also
connect
to
private
IPS,
like
with
ipsec,
if
the
VPN
that
you're
using
offers
something
like
Nat,
traversal
wireguard
has
built-in
authentication
and
encryption
Margaret
uses
the
stream
Cipher
Cha-Cha
20,
and
encryption
for
encryption
and
poly
1305
for
Authentication
authorization
is
managed
based
on
the
configured
list
of
peers.
So
if
a
device
has
a
peers
public
key,
then
they
can
communicate
and
there's,
but
there's
no
other
authentication
built
in
again
like
with
ipsec
vpns
that
are
built
on
top
of
wireguard
would
add
authorization.
A
B
Yeah
so
since
I
work
at
TL
scale,
we're
gonna
demo
tail
scale
using
tail
scale
to
reach
a
kubernetes
service
internally
in
this
tail
scale
is
a
wireguard-based
mesh.
Vpn
mesh
Network
means
that
traffic
doesn't
go
through
a
concentrator,
but
connections
are
directly
peer-to-peer.
So
you
get
better
latency.
You
you're,
not
there's
no
single
point
of
failure
and
it
because
it's
based
on
wireguard
all
of
your
connections
are
always
encrypted
from
like
one
device
to
a
different
from
any
device
on
to
any
other
device.
It
will
always
be
into
an
interoper.
B
B
B
B
B
B
This
shows
again
standard
nothing,
interesting,
I'm
going
to
now
apply
this,
and
we
can
see
that,
as
we
were
speaking
talking
about
this
earlier,
we
have
a
cluster
IP
that
we
can
now
read.
Well,
if
we
were
in
it
in
the
cluster,
we
could
hit
it.
If
I
do
this,
oops
nothing
will
happen,
but
what
I
can
do
is
I
can
do
port
forward.
I
have
port
forward
somewhere
yeah
there
you
go
and
then
I
can
go
to
localhost,
5000
and
I.
B
B
And
you
can
see
that
things
are
coming
up
and
things
are
there
and
as
the
telescope
upper
starts,
it
joins
my
cluster.
Oh,
it
joins
my
tail
net.
You
can
see
that
this
I
have
tail
scale
running
here
and
there's
the
operator
is
here:
it's
not
that
interesting.
Yet
we'll
we
have
some
plans
on
how
to
make
this
more
interesting,
but
anyways
back
to
this.
B
So
now,
I
have
the
kubernetes
operator
line
I'm
going
to
do
a
diff
of
this,
and
this
now
to
show
you
that
all
I'm
doing
is
basically
making
a
load
balancer
class
I'm,
changing
it
from
this
is
mini
Cube
running
on
my
laptop
I'm,
going
to
say
that
no
make
it
a
load
balancer
instead
of
a
cluster
IP
and
use
a
tailscale
load.
Balancer
class
I
also
tell
it
to
use
the
demo
hostname.
B
So
you
will
see
that
details
here
operator
has
spun
up
a
new
pod
and
has
given
me
a
a
URL
that
I
can
hit
okay,
so
I'm
going
to
hit
this
URL
on
my
machine,
and
this
is
not
going
to
work,
but
this
might
hopefully
maybe
if
I'm
lucky.
Oh,
it
does
work
right,
no
Port
forwards.
No,
nothing
I
have
something.
That's
running
on
this
I
hope
that
it
doesn't
isn't
always
this
slow,
but
I
guess
Wi-Fi,
it's
fine.
B
While
we
wait
for
this
to
do
stuff,
what
we're
going
to
do
is
we're
going
to
use
a
new
feature-
and
this
is
this
is
not
part
of
the
operator
that
we're
about
to
drop.
This
is
coming
soon,
but
I,
it's
in
a
branch
somewhere
that
I'm
working
on.
But
what
this
does
is
so
there's
a
I'm,
sorry
yeah,
it's
it's
like
literally
ours
old,
so
we're
gonna,
and
this
is
the
other
one
which
is
glances
funnel
with
this.
B
B
A
B
B
B
Can
hit
my
laptop?
My
service
is
running
on
this
cluster,
so
this
is
obviously
this
is
not.
You
would
not
expose
an
internal
service
like
this,
but
you
could
use.
You
can
use
sales
skill
to
expose
the
service
running
basically
anywhere
in
the
world
either
on
kubernetes
are
not
in
kubernetes
and
access
it
from
anywhere
in
the
world
without
doing
any
port
forwarding
without
like
I'm,
on
a
public
Wi-Fi
in
some
conference,
and
it
works.
A
So
it
was
spinning
up
a
service
of
a
load,
balancer
class
type
on
on
kubernetes,
adding
a
true
telescope
Network,
which
then
made
it
accessible
to
anybody
else,
who's
on
your
telescale
network,
who
has
authentication
encryption?
All
that
goodness
just
like
you
would
want
for
an
internal
service
and
then,
if
you
wanted
to
make
it
publicly
accessible
like
if
you
were
trying
to
share
a
link
with
a
partner
of
you,
know
something
in
CI
CD
that
you
were
developing
or
that
type
of
thing
you
can
just
share.
You
can
easily
get
I
am.
B
B
B
A
A
A
All
right,
so
we
did
a
demo
again
thanks
for
the
demoism,
so
we've
covered
all
the
options
that
we
had,
and
none
of
them
provides
all
the
properties
that
we
were
looking
for,
which
is
not
shocking.
Nonetheless,
let's
go
look
back
at
the
options
that
we
considered
and
how
they
stack
up
and
I'm.
Sorry
that
the
text
is
so
tiny,
there's
too
many
options
and
two
criteria
so
for
the
kubernetes
constructs
you
know
combining
kubernetes
cluster
services
with
load.
Balancer
gets
you
load
balancing,
that's
it.
A
It
gives
you
inbound
connectivity
from
outside
the
cluster
to
Services
running
inside
of
it
combining
kubernetes
cluster
services
with
kubernetes
Ingress
gives
you
encryption
and
load
balancing
you
can
still.
You
know
you
can
Route
traffic
into
a
cluster
with
TLS
that
terminates
at
Ingress,
which
may
or
may
not
be
inside
the
cluster.
A
With
kubernetes
network
policy
you
can
restrict
which
Services
inside
a
cluster
can
communicate
with
which
other
services,
including
restricting
a
service
to
only
access,
accept
traffic
from
Ingress,
then
for
the
set
of
options
that
are
typically
used
for
other
kinds
of
trafficking,
kubernetes
service
mesh.
Does
it
everything
or
it
can
in
some
cases,
depending
on
what
you're
trying
to
do
so?
Why
shouldn't
you
use
a
service
mesh
for
the
user
to
internal
service
use
case?
A
Well,
you
can
again,
you
just
need
a
user
to
install
the
service
mesh
agent
on
all
user
machines
which
ends
up
looking
a
lot
like
a
VPN
right.
A
Bastion
is
a
single
point
of
entry
to
your
network.
It
typically
provides
authentication
authorization,
encryption
and
auditability,
but
it
sits
on
the
public
web
and
it
might
have
some
traffic
management
capabilities.
A
If
that's
something
that
you
need
and
then
for
protocols
that
are
used
to
protect
traffic,
that
we
talked
about
and
are
typically
used
as
part
of
a
VPN
ipsec
gives
you
authentication
and
encryption
and
ipsec-based
VPN
will
typically
provide
you
with
authorization
and
auditability
and
may
have
some
traffic
management
options
and
similarly,
wire
guard
can
be
used
anywhere,
that
you
wrote
traffic,
but
only
gives
you
authentication
and
encryption
with
authorization
based
on
public
Keys.
A
wire
guard
based
VPN
will
typically
provide
you
with
authorization
and
auditability
and
might
have
some
traffic
filtering.
A
So
the
option
that
you
should
choose
for
your
application
doesn't
only
depend
on
security
properties
right
as
I
mentioned
earlier.
You
also
think
about
you
know:
latency
availability
usability,
it's
a
huge
reason
to
decide
what
to
do
for
your
internal
users
as
well
as
ease
of
management
of
whatever
solution
you
pick,
but
there
isn't
a
clear
winner,
so
I
have
this
very
you
know
every
solution
has
its
trade-offs.
I
know
it's
a
very
unsatisfying
conclusion
to
this
talk,
but
here
we
are,
nobody
wins,
but
also
nobody
loses,
which
is
all
right.
A
B
B
A
C
A
B
C
A
If,
like,
if
wire
guard
breaks,
they
have
to
redo
like
if
the
underlying
encryption
breaks,
they
have
a
way
of
changing
like
a
version
number
but
then,
like
everything
else,
every
single
bit
is
used.
Basically
right,
there's
no
there's
nothing
over
there's!
No
overhead
I,
don't
know
about.
If
he's
like
yeah.
C
B
B
Yes,
so
tail
scale
has
a
feature
called
tailscale
SSH,
which
does
basically
that.
So,
if
you
can
install,
if
you
install
jail
scale
on
your
nodes,
you
can
restrict
who
can
access
your
nodes
and
as
what
user?
And
it
runs
its
own
SSH
agent
on
the
machine.
So
it
gets
a
lot
more
fine-grained
access.
You
can
there's
also
a
Mode
called
check
mode,
so
you
can
say,
like
Maya
needs
to
re-authenticate
every
four
hours
in
order
to
reach
the
servers.