►
From YouTube: Using Envoy as an Egress Proxy for TLS Enabled Traffic - Amit Jain & Kiran Kumar, VMware
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Using Envoy as an Egress Proxy for TLS Enabled Traffic - Amit Jain & Kiran Kumar, VMware
Modern apps are increasingly relying on using external 3rd party services (such as Twilio for e.g) and shared cloud services (such as S3 for e.g.). External interactions are important not only for security but for the app's continuity and resiliency as well. The use of Envoy as an egress proxy for external interactions has been limited though, mostly as the external interactions are TLS protected and Envoy is not able to decrypt the external TLS sessions. This session demos a solution that enables Envoy as an egress proxy for external access. It builds upon a combined approach of deploying Envoy as a transparent egress sidecar proxy along with the SSLproxy (github.com/sonertari/SSLproxy). In this approach, SSLproxy acts as a transparent TLS interception proxy and Envoy provides traffic management & security on the decrypted traffic. We dive into the traffic stitching mechanism and a new Envoy listener filter that acts as the glue between Envoy and SSLproxy and extends Envoy for the integrated solution.
A
Welcome
everyone
to
the
session
on
using
onward
as
a
rigorous
proxy
for
tls
enabled
traffic.
Briefly
introducing
myself.
My
name
is
amit
jain,
I'm
presently
leading
the
application,
security
and
services
team
at
vmware
for
modern
and
cloud
native
applications
prior
to
vmware.
I
was
the
founder
for
mesh
7
and
served
as
cto
at
mes7
we
developed
application
security
mesh
for
distributed
cloud
native
applications.
A
A
To
start
with
cloud
native
and
modern
application
architecture
have
become
the
new
normal.
They
offer
tremendous
benefits
in
terms
of
developer
productivity
and
innovation
agility,
but,
of
course,
with
great
power
comes
great
responsibility.
In
this
case.
It
is
about
securing
this
new
infrastructure
against
the
new
security
challenges
that
are
surfacing
with
modern
applications.
A
A
Now,
as
we
enter
into
the
microservices
network,
we
need
to
worry
about
lateral
movement
of
threads
and
least
privileged
communication
between
services
and
data.
At
the
microservices
network,
we
enforce
security
controls
using
cni's
kubernetes
policies
and,
most
recently
using
service
mesh
at
the
application
and
api
layer
and
finally,
modern
applications
are
increasingly
relying
on
external
third-party
services,
such
as
julio's
box,
for
example,
or
shared
cloud
services
such
as
s3
and
legacy
applications.
A
Now,
let's
consider
the
need
of
egress
connectivity.
Connectivity
is
the
must
have
for
a
cloud
native
apps
functionality
as
we
covered
briefly
in
the
previous
slide.
Cloud
native
apps
are
increasingly
using
external
third
party
services
for
different
important
functions,
such
as
books,
tui
for
communication,
etc.
A
Applications
are
also
increasingly
using
shared
ingress
cloud
services
that
are
provided
by
cloud
service
providers
such
as
s3
and
rds
for
database
etc,
and
they
are
also
reaching
out
to
the
on-premise
legacy
apps
that
may
be
deployed
on-prem
or
in
the
non-container
workloads,
such
as
vms
or
metal.
For
example,
all
of
the
bow
usage
of
egress
services
requires,
or
makes
the
e-class
connectivity
a
must
to
have
for
cloud
applications
and,
at
the
same
time,
bilateral
connectivity
is
required.
A
It
also
causes
a
different
type
of
security
risk
and
challenges,
for
example,
in
case
of
attacks
that
deploy
the
persistent
back
doors
in
this
connectivity
can
be
used
to
connect
to
the
command
and
control
servers
for
a
compromised
workload.
They
reach
out
to
malicious
site
to
download
a
malware
such
as
ransomware
ignorance.
Connectivity
can
also
be
exploited
for
for
data
exploration.
A
hacker
may
access
the
cloud
resource
such
as
s3
bucket
and
then
can
read
the
data
and
upload
it
to
an
eps
server,
now
being
able
to
observe
and
secure
accuracy.
A
A
A
So,
let's
take
a
look
at
tesl
proxy,
so
we
are,
we
are
proposing
in
this
session.
We
are
proposing
the
use
of
sl
proxy,
along
with
one
way
to
achieve
egress
observability
sl
proxy
is
a
full
proxy
that
intercepts
our
tls
connection,
decrypts
the
traffic
and
diverts
traffic
to
other
programs
for
processing
and
deep
inspection
of
pls
traffic.
It's
open
source
and
bsd
licensed
it
is
used
widely
and
it
is
used
by
utm
firewall
project
to
provide
a
deep
tls
interception
for
web
op3
and
p
traffic.
A
It
supports
many
pls
protocol,
including
ssl
dot,
o
and
dls
1.3.
It
supports
tls
extensions
such
as
smi,
and
it
is
able
to
work
with
most
of
the
cipher
suits,
including
a
recent
one
and
rsa
dpl
then,
and
ec
dsa,
dsa,
etc.
Additionally,
it
supports
advanced
features
such
as
user
authentications,
and
also
when
we
actually
intercept
tls.
A
One
of
the
key
requirement
is
that
the
intercepting
proxy
needs
to
make
sure
that
it
is
connecting
to
a
valid
back-end
server
and
it
is
to
do
things
such
as
certificate,
validation,
etcetera,
sl,
proxy,
provides
supports
of
certificate
validation
when
it
does
the
tls
interception.
It
ensures
that
the
certificate
presented
by
the
backend
server
is
valid
and
if
it
finds
it
to
be
invalid,
it
terminates
the
tls
flow.
A
It
then
performs
the
tls
handshake
with
the
destination
server
on
behalf
of
the
application
and
rewrites
the
server
provided
certificate
to
forge
it
and
to
generate
an
efficient
certificate
towards
the
application
using
a
local
root
ca
which
can
either
be
user
provided
or
automatically
created.
And
we
will
cover
that
in
the
in
some
more
details
in
the
next
few
slides.
Now.
The
roots
here
used
by
sl
proxy.
A
One
of
the
one
of
the
the
main
feature
of
sl
proxy
is
that
it
it
can
redirect
decrypted
tls
traffic
to
an
external
program
for
further
processing
and
inspection
and
external
program
can
process
the
traffic
and
then
can
redirect
the
traffic
back
to
a
syntax.
And
this
allows
the
sl
proxy
to
be
deployed
as
as
a
as
a
as
a
proxy
which
provides
the
access
to
pls
encrypted
traffic,
which
is
the
main
feature
we
are
using,
while
deploying
it
with
the
owner.
A
Now,
let's
take
a
look
at
how
it
works,
so
sl
proxy
mine,
supporting
the
redirection
of
the
decrypted
traffic
to
an
external
program.
This
is
a
protocol
called
lesser
proxy
protocol
and
the
way
it
works
is
that
distal
proxy
insert
a
connection
matter
or
time
to
the
first
packet
in
the
in
the
connection.
A
On
behalf
of
the
application
now
upon
receiving
the
tls
certificate
from
external
service,
it
uses
external
services,
information
from
the
certificate
to
generate
an
ephemeral
certificate
and
science
it
using
a
local
root,
ca
which
can
be
automatically
created
or
user
provided
and
forwarded
to
the
application.
So
what
cost
application
is
a
forced
certificate
which
is
issued
by
sl
proxy
and
which
is
based
on
the
detail
which
is
received
from
the
external
service,
so
the
application
basically
thinks
that
it
is
communicating
with
external
service.
A
So
the
way
it
works
is
that
when
the
application
now
sends
the
data
to
the
external
service,
xl
proxy
decrypts,
the
data
and
forwards,
the
decrypted
data
to
the
online
using
the
sl
proxy
protocol
onward,
receives
the
decrypted
traffic
and
can
provide
the
observability
and
processing
on
the
eclipse
traffic.
And
then
it
sends
back
the
traffic
to
sl
proxy
or
an
ip
port
that
is
specified
in
that
cell
proxy
header,
sl
proxy
re-encrypts.
The
traffic
and
forwards
it
to
the
back
to
server
written
traffic
follows
the
same
path.
A
The
response
comes
from
the
external
services
xsl
processor
receives
the
response,
sends
it
back
after
decrypting
it
to
one
y
onward
processes.
The
response
sends
it
back
to
the
cell
proxy
sl
proceed
and
then
re-encrypt
it
back
to
the
application
and
application
receives
the
response
now
to
be
able
to
use
the
ony
as
an
external
program
with
a
superproxy,
we
needed
to
add
the
support
of
ssl
proxy
protocol
termination
in
onward,
and
this
is
done
using
a
new
listener
filter
in
onward,
which
we
are
calling
sc
proxy.
A
What
this
new
listing
filter
does
is
that
it
attaches
itself
to
the
listener
and
then
it
says
subscribes.
It
reacts
to
the
accept
event
and
in
the
accept
even
it
subscribes
to
the
socket
or
file
event
for
read
data
once
it
receives
the
read
data
event.
It
looks
for
the
sl
proxy
header
and
once
it
receives
the
sl
proxy
header,
it
passes
the
sl
proxy
header.
It
extracts
the
information
about
the
client
ipn
for
the
description
of
this
ipl
code
and
the
dynamic
address
of
itself.
A
It
then
uses
this
information
to
set
the
flow
metal
data
in
in
a
way
that
pro
is
seen
as
coming
from
the
client
ipn
port
and
also
it
basically
forwards
the
traffic
to
sl
proxy
back
once
it
has
done
that,
once
it
has
processed
as
the
proxy
header,
it
disables
itself
by
unsubscribing
to
the
file
event
and
continuing
the
filter
change,
which
makes
that
all
the
future
interaction
between
the
application
and
the
backend
service.
Although
all
the
data
which
is
received
on
this
flow
goes
back
to
the
application.
A
In
this
case,
the
static
key
connection
manager,
filters
and
sl
proxy
filter
is
no
more
active
in
the
path
after
it
has
processed
there's
some
proxy.
Now,
let's
quickly
go
over
how
we
use
the
above
solution
and
institute
deployment
to
achieve
observability
of
dls
track
so
deploying
the
solution
in
the
sd
environment
required
few
modifications
to
the
sq
cycle.
First,
this
new
sidecar
image
is
modified
to
include
the
sl
proxy
binary
and
associated
script
to
set
up
and
initialize
ssl
proxy.
A
We
also
needed
to
add
the
ip
table,
rules
for
redirecting
the
applications,
tls
traffic
to
supports,
and
finally,
we
needed
to
integrate
with
the
stos
control
plane
to
add
a
new
listener
in
onward
sci-fi
proxy
that
has
a
ssl
proxy
filter
and
captures
the
traffic
from
sl
proxy
to
and
provides
the
observability
on
it.
We
also
added
a
new
cluster
in
onward
sidecar
proxy,
with
the
original
dst
load
balancing
method.
A
This
briefly
shows
how
we
are
starting.
The
sl
proxy
inside
the
container
inside
the
initialization
script
is
a
standalone
script
and
performs
two
steps.
First,
it
creates
a
temporary
root
csr
for
each
port
and
then
it
initializes
vessel
proxy
inside
the
site
path.
Few
of
the
key
parameters
are
described
on
the
above
slides.
These
parameters
provide
basic
configurations
such
as
listening
port
and
the
user
id
for
the
sql
proxy
process
for
redirecting
applications,
dls
traffic
to
sl
proxy.
A
We
also
added
a
new
cluster
in
onward
site
that
proceed
with
the
original
dst
load,
balancing
method.
This
provides
a
transparent
proxy
semantics
program
online,
now
we'll
briefly
demo
the
solution
and
using
the
book
info
app
in
the
sql
deployment,
and
I
will
transfer
it
over
to
kiran
for
further
thanks.
B
B
B
B
Now
this
is
the
online
safety
field,
filter
crd,
which
has
the
following
configuration,
there's
a
new
listener
that
we
add
and
which
listens
to
the
port
1090,
and
it
has
a
flag
called
usb
ssl
proxy
pro.
This
flag
indicates
that
this
listener
expects
the
ssl
proxy
protocol
header
to
be
present
when,
on
the
new
connection,.
B
Now
this
is
the
listener
that
got
added
successfully,
so
we
added
this
new
listener.
This
new
listener
has
this
ssl
proxy
filter
added.
It
receives
all
the
decrypted
traffic
from
the
ssl
proxy,
using
the
ssl
proxy
filter.
It
terminates
the
ssl
proxy
header
and
then
it
forwards
to
the
cluster.
The
cluster
external,
which
has
this
virtual
destination,
enabled.
B
So
I
am
telling
the
logs
here
so
that
we
can
see
that
telemetry
data
sent
by
onward
process.
Now
now
I'm
going
to
access
the
product
page
now,
as
I
explained
earlier,
the
product
page
fetches,
the
data
from
external,
secure
site,
the
code
information
and
then
it
displays
it.
So
now,
let's
access
the
product
page.
B
And
if
you
see
the
with
the
verbose
thing,
you
can
see
that
the
client
initial
request
to
the
external
secure
site
was
redirected
to
the
ssl
proxy,
which
was
listening
to
the
port
8443,
as
explained
earlier
in
the
presentation.
This
data
is
then
decrypted
by
ssl
proxy
and
then
the
decrypted
traffic
is
then
passed
to
envoy
for
further
analysis.
B
Now,
looking
at
the
telemetry
log,
the
telemetry
log
shows
that
the
destination
ip
the
destination
host
information
and
it
has
the
url
information
and
it
has
the
source
source,
workload,
product
information
and
the
user
agent
and
etc.
So,
with
this
information,
we
can
enable
policy
enforcement
and
also
the
analytics
and
and
do
the
other
required,
etc.
Things.
A
We
plan
to
work
with
the
student
community
to
make
this
part
of
the
stu,
and
that
will
require
us
to
enhance
the
site
car,
as
well
as
a
deeper
integration
with
the
steel
service,
entry
paradigm
for
tls
configuration
and,
of
course,
this
demo
we
only
covered
the
observability
part.
We
plan
to
also
integrate
with
the
traffic
management
and
authorization
policies
to
be
able
to
make
them
accessible
on
the
external
tls
services,
and
the
final
piece
is
around
the
root
ca.