►
From YouTube: Securing Cloud Native Communication, From End User to Service - Daniel Bryant & Nic Jackson
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
Securing Cloud Native Communication, From End User to Service - Daniel Bryant, Datawire & Nic Jackson, HashiCorp
Everyone building or operating cloud native applications must understand the fundamentals of security issues and modern threat models. Although this topic is vast, in this talk Nic and Daniel will focus on the end-to-end communication and higher-level networking threats, and explore how the combination of an edge proxy and service mesh using TLS and mTLS can be used to mitigate many man-in-the-middle attacks. Key takeaways include: - An understanding of the "three pillars" of service mesh functionality: observability, reliability, and security. A service mesh is in a unique place to enforce security features like mTLS - Learn how to ensure that there are no exploitable "gaps" within the end-to-end/user-to-service communication path. - Explore the differences in ingress/mesh control planes, with brief demonstrations using Ambassador and Consul Connect
https://sched.co/MPev
A
Welcome
one
thanks
for
coming
along
appreciate.
That
is
a
lot
of
like
good
choices
that
this
conference
isn't
there
so
really
appreciate
you
attending
at
the
end
of
day,
we'll
do
our
best
to
make
it
fun.
So,
if
you're
not
here
for
securing
cloud
native
communication
from
end-user
to
service,
now
is
the
time
to
escape
yeah.
If.
A
Yes
and
learn
something
different
so
in
issues
ourselves
in
just
a
second,
but
just
to
set
up
a
bit
of
like
TLDR
thingy
for
the
millennials
in
the
room,
and
we
are
seeing
an
increase
even
though
we're
at
a
cloud
native
conference.
The
reality
is
that
many
of
us
have
got.
You
know:
data
centers,
private
kind
of
cloud,
we're
not
all
on
the
public
cloud,
yet
there's
definite
drive
towards
app
modernization,
hybrid
platforms,
clouds,
internal
DC,
that
kind
of
thing,
but
decoupling,
applications
and
infrastructure
seems
to
be
a
winner
workload.
A
Portability
take
advantage
of
sort
of
ml
in
the
cloud,
these
kind
of
things
to
decouple.
You
need
to
use
things
like
containers,
packaging
and
also
things
like
more
advanced
networking
which
we'll
cover
today.
You
need
to
do
it
incrementally
and
the
key
one
today
we're
going
to
discuss
is
you
need
to
make
this
move
securely?
A
A
B
We
don't
want
to
scare
you,
but
we
we
almost
do
because
I
think
some
of
the
things
that
Daniels
mentioned
it's
about
security
and
security
is
a
real
problem,
but
security
is
also
something
that
we
should
take
seriously
because
security
has
very
real
threats.
So
some
of
the
things
214
that's
records
of
data
personally
identified
a
identifiable
data
which
is
stolen
every
second
right.
That's
fairly
astounding.
B
Sixty
five
percent,
so
identity
theft
and
one
of
the
kind
of
the
core
trends
that
has
been
seen
in
the
industry,
around
sort
of
malicious
actors
and
and
data
theft,
is
that
identity
theft
can
actually
generate
a
lot
of
revenue.
So
if
you're
kind
of
thinking
in
the
mindset
that
somebody
is
only
after
financial
transactions,
only
after
credit
card
numbers,
there's
actually
money
to
be
made
just
on
names
addresses
personally
identifiable
data
which
can
be
sold
on
the
black
market.
B
A
You
Nick,
so
security
is
a
massive
topic,
genuinely
massive
topic.
If
you
haven't
and
sort
of
really
covered
it
before
or
you're.
Looking
to
learn
more
I
thoroughly
may
recommend
this
book.
Adam
Shostak
it
dives
in
quite
you
know
quite
a
deep
level
at
threat
modeling,
but
you
can
do
threat
modeling
very
cost-effectively
on
your
projects
may
take
a
little
while
to
learn
that
applications
is
like
doing
your
good
architecture
or
good
code
reviews
doing
good
threat.
Modeling
is
highly
highly
valuable.
I
thoroughly
encourage
you
to
do
this.
A
We
are
going
to
make
some
assumptions
in
35
minutes.
To
be
honest,
we're
going
to
assume
that
you've
secured
your
data
arrest
and
you've.
You
know
hardened
your
infrastructure,
these
kind
of
things.
We
are
mainly
interested
in
data
in
motion
here,
yeah,
one
small
part:
are
your
communications
vulnerable,
a
whole
bunch
of
breaches?
These
days
happen
with
bad
dependencies.
People
basically
can
fire
up
a
shell
inside
your
perimeter
and
move
laterally
in
your
data
center.
A
That's
where
a
lot
of
damage
can
really
happen
as
you
bring
in
more
more
different
things
to
your
stack
as
you
kind
of
modernize,
your
applications.
I
generally
see
like
in
consulting
work
that
the
network
heterogeneity
increases
rapidly
yeah.
We
know
we
all
know
and
love
kubernetes,
but
you
get
some
cloud
in
there
different
flavors
of
cloud,
your
internal
data
center
and
I'm
very
much
reminded
of
a
bunch
of
mistakes
I've
made
in
my
career
in
relation
to
the
eight
fallacies
of
distributed
computing.
A
If
you
haven't
read
this
paper,
it
is
a
must
read
yeah,
like
honestly
I've
made
so
many
split
when
I
started
my
career
working
with
and
and
making
assumptions
about,
my
local
disk
storage
versus
cloud
storage
bunch
of
problems
like
this,
but
when
we
do
try
and
make
our
network
more
heterogeneous,
we
move
to
the
cloud
things
like
that.
These
things
were
pulling
out
change
a
lot.
We
really
need
as
engineers.
We
need
mechanical
sympathy
with
the
underlying
infrastructure.
We
need
to
be
able
to
understand
key
properties,
and
you
can
see
number
four
there.
A
One
of
the
assumptions
one
of
the
fallacies
is
the
network
is
secure.
Yeah.
We
really
need
to
think
about
these
kind
of
things.
So,
as
an
example,
sort
of
end-to-end
comms
you
imagine,
we've
got
like
are
usually
coming
in
the
bottom
or
we've
got
to
say
two
data.
Centers
say
that
some
VMS
and
we
got
some
kubernetes
here.
We've
got
a
user
coming
in
the
bottom
into
a
gateway
I'm
using
Ambassador,
very
wire.
We
actually
created
a
master
open
source
project.
You
can
download
that,
but
you
also
want
to
secure
the
communication
between
services.
A
We're
using
console
again
open
source
for
service,
discover
it
here,
you
can
mix
and
match
through
text
you
can
choose.
Nginx
traffic
at
the
front
is
steo
other
things
in
there
in
that
it's
are
in
the
mix,
but
we
look
because
of
the
companies
in
technology.
We
use
we've
chosen
these
as
examples,
but
you
also
need
to
secure
everything
going
across
data
centers
across
clusters
and
identity
between
these
kind
of
different
services.
A
A
These
days,
a
bunch
of
assumptions
we
used
to
make
are
wrong.
Yeah
things
like
zero
trust
networks
are
really
becoming
a
thing
because
you
can
guarantee
there
is
not
bad
actors
in
your
system
yeah.
You
know
we
used
to
kind
of
look
at
the
perimeter
as
they're
kind
of
the
last
line
of
defense
and
assume
everyone
inside
was
good.
This
is
not
the
case
anymore.
Now,
I'm
not
saying
forget
about
the
edge
the
edge.
A
It's
super
important
if
I've
learned
one
thing
from
Star,
Wars
and
I've
actually
learned
many
things
from
Star
Wars,
but
I've
learned.
One
thing
is
always
be
on
the
lookout
for
one
perhaps
eyes
holes
in
my
edge
defenses
yeah.
This
is
a
really
key
thing,
but
you've
also
got
to
combine
the
thing:
it's
no
good,
having
really
strong
front
door
and
then
a
really
weak
kind
of
you
know
internal
system.
What
we're
trying
to
pitch
here
is
you.
We
need
to
think
about
this
stuff,
end-to-end,
just
a
quick
refresher.
A
If
you're
looking
at
sort
of
definitions,
API
gateways
edge,
proxies
ADC,
like
applications
and
every
controllers,
often
wrapped
into
similar
kind
of
area,
they're
really
about
exposing
internal
services
to
end-users
yeah.
This
is
the
key
thing.
Typically,
you
know
buying
multiple
domains,
multiple
kind
of
hosted
sites,
you're
encapsulating
the
back
end.
A
Your
user
should
not
care
or
not
know
what
your
systems
are
running
on,
be
there
kubernetes
cloud
whatever
and
as
a
bunch
of
cross-cutting
concerns,
the
Gateway
focuses
on
TLS
termination,
end
user
or
maybe
using
key
cloak
or
CRO
that
kind
of
thing
and
rate-limiting.
You
were
bad
actors.
You
know
trying
to
do
denial
of
service.
These
kind
of
things
you
do
want
to
stop
at
the
edge.
A
The
big
challenge
with
some
app
modernization
is
we're
moving
very
much
from
a
static
world
where
we
knew
our
IPS
and
we
knew
our
kind
of
clusters
to
a
high
leg.
Highly
dynamic,
multi-cloud
world,
where
containers
are
coming
up
and
down,
pods
are
coming
up
and
down.
Services
are
rapidly
changing
from
the
service
mesh
or
we're
also
collect
proxy
mesh.
The
nginx
folks
call
it
the
fabric
model.
You
really
hear
exposing
internal
services
to
insert
internal
consumers
and
your
encapsulating
the
service
infrastructure.
A
Again,
if
you're
an
internal
developer
engineer,
you
don't
really
care
where
the
other
services
hosted,
you
want
to
write
to
it.
Yeah.
You
also
want
a
bunch
of
cross-functional
sort
of
things
to
be
done
there,
such
as
MPLS
that
identity
that
mutual,
like
a
sort
of
trust,
we've
got
for
mutual
identity,
verification
between
services.
You
want
things
probably
like
access
control
lists.
You
maybe
want
to
define
intentions
which
Nikhil
cover
in
a
moment,
as
in
I,
only
intend
the
front-end
to
be
able
to
speak
to
the
web
server
and
not
the
database.
A
So
if
the
front-end
gets
compromised,
it
can
only
do
so
much
damage,
you're
gonna,
move
laterally.
So
far,
we've
mentioned
the
three
pillars
and
they
can
I've
chatted
about
this.
Quite
a
bit.
The
three
pillars
of
service
meshes
and
we've
heard
a
bunch
about
service
meshes
at
this
conference.
They
are
focused
around
observability
reliability
and
security.
Yeah
service
meshes
are
not
easy
to
run
and
we've
had
to
go
a
few
clients,
and
but
they
do
offer
a
lot
of
value
when
done
right,
yeah
and
we
are
very
much
focusing
on
security
nikka.
A
So
the
animation
is
a
Spencer.
You
can
imagine
the
arrows
moving
yeah,
but
what
I'm
trying
to
say
there
is
basically
the
kind
of
the
flow
is.
A
user
makes
a
request.
It
hits
the
gateway,
it
will
then
often
kind
of
get
forked
yeah,
maybe
you're
doing
like
a
scatter
gather
kind
of
thing.
The
the
gateway
talks
to
further
downstream
services.
You
can
see
the
little
side
cars
there
there
little
proxies
and
then
that
service
may
in
turn
call
other
services
yeah
to
do
its
work.
A
Now
the
red
arrows
are
basically
sort
of
points
of
attack.
Clearly,
the
front
door
is
going
to
be
under
attack,
it's
exposed
publicly,
but
if
an
attacker
does
get
inside
all
the
other
red
arrows
sort
of
the
the
gap
between
say,
maybe
you're
terminating
TLS
at
the
edge
and
then
not
enabling
TLS
further
into
the
cluster,
all
the
comms
going
across
data
centers,
you
want
to
make
sure
they're
secure
TLS
because
that
traffic
may
go
on
the
internet.
For
example,
people
can
be
sniffing
for
that
kind
of
thing.
A
B
So
just
kind
of
recapping
on
on
the
problem,
and
the
problem
is
that
we
put
a
lot
of
trust
into
the
primitive,
and
rightly
so.
Firewalls
are
great,
but
the
key
thing
is:
if
you
again,
if
you
look
at
a
lot
of
vulnerabilities
which
have
been
happening
over
the
last
couple
of
years,
a
lot
of
those
things
are
happening
inside
of
application
frameworks,
so
very
popular,
open
source
application
frameworks,
an
attacker
finds
a
vulnerability.
They
have
an
ability
to
do
a
remote
code,
execution
inside
of
your
network.
B
B
So
what
we
need
to
do
to
solve
this
is
we
kind
of
need
to
look
at
the
problem,
not
as
a
perimeter
firewall,
but
we
almost
need
each
service
to
have
a
clearly
defined
bound
of
trust.
A
clearly
defined
internal
service
segments
and
the
service
match
really
enables
you
to
do
this,
and
why
do
we
need
it?
Why
can't
we
just
use
the
traditional
methods?
I
mean
what
are
these
traditional
methods?
Some
of
you,
you
know,
may
not
know
but
network
segmentation.
B
B
Network
segmentation
was
conceptualized
pretty
much
well
when
that
came
out
when
people
realized
that
they
could
no
longer
protect
their
networks
using
a
castle
and
moat
using
four
walls,
but
the
problem
when
you
start
to
look
at
network
segmentation,
is
you
start
to
think
about?
Well,
we
don't
run
single
vm's
anymore,
we're
running
multi-talented
applications
in
our
scheduler,
we're
running
many
pods
on
many
nodes,
so
we
have
to
start
the
thing
deeper.
We
have
to
start
think
about
in
terms
of
service
level.
B
Simple.
Well,
it's
not
that's
the
core
problem.
The
core
problem
is
that
we're
working
in
a
dynamic
environment
and
the
dynamic
environment
is
great,
because
the
dynamic
environment
is
what
gives
us
reliability
and
availability
and
allows
us
to
do
all
sorts
of
amazing
deployments,
and
you
know
the
stuff
that
you
know
and
love
where
it
causes
a
problem
with
network
security
in
the
traditional
sense
is
that
network
security
is
thinking
in
terms
of
fixed
point
network
locations.
B
It's
thinking
in
terms
of
a
service
running
on
a
virtual
machine
at
a
known
location,
which
is
talking
to
another
service
and
another
known
location.
When
you
start
to
have
schedulers.
Well,
you
don't
know
what
that
location
is.
You've
got
overlay
networks,
the
IP
address
of
the
source
is
potentially
not
going
to
be
the
IP
address.
Or
how
do
you
build
that
firewall
rule?
How
do
you
configure
the
routing
tables
to
allow
traffic
between
a
pod,
which
you
don't
know
where
it
exists
to
another
machine
which
is
on
a
completely
different
network?
B
And
you
probably
do
this-
you
probably
white
lists
the
entire
cluster,
because
it's
just
so
difficult
to
do
it
other
ways,
but
you've
just
opened
up
your
network.
If
I
can
exploit
a
find
a
remote
code
execution
inside
your
front-end
application,
if
I
can
get
inside
your
firewall,
if
I
can
move
laterally,
if
you've
got
50
million
records,
that
can
cause
you
three
hundred
and
fifty
million
dollars
worth
of
financial
damage.
It's
it's
a
very
big
and
very
real
problem.
It's
also
not
that
difficult
to
fix.
A
I
hear
a
lot
of
talk
about
control,
planes
and
data
planes,
but
people
often
don't
take
the
time
to
explain
so
Matt's
on
a
fantastic
article
here.
If
you
do
want
to
know
more
about
the
difference
in
control,
planes
and
data
planes
thoroughly
recommend
that
article.
But
the
key
thing
is
the
data
plane.
In
our
case,
other
proxies
are
doing
the
heavy
lifting
yeah
and
both
in
Ambassador
API
gateway
and
console.
The
proxies
happen
to
be
envoy,
which
we,
you
know,
CN
CF,
project,
I'm
sure
many
of
you
know
and
love.
A
There's
many
other
proxies
out
there
honey
in
the
vendor
booth.
You
can
go
and
have
a
look,
but
the
key
things
are
the
things
doing.
The
heavy
lifting
are
the
data
plane,
the
actual
proxies
themselves,
they're
being
controlled,
and
the
telemetry
is
coming
back
to
the
control
plane
now
or
I
put
the
name
of
that.
So
what
I
would
say
is
north
south,
it's
fundamentally
a
bit
different
in
terms
of
ingress,
there's
unknown
or
untrusted
people.
A
Basically
coming
into
your
cluster
yeah
when
you're
dealing
with
internal
traffic,
you
pretty
much
can
guarantee
a
certain
level
that
we're
saying
be
careful,
of
course,
but
you
can
pretty
much
guarantee
a
certain
level
of
trust
or
all
the
way
the
things
are
operating.
But
when
you
expose
something
to
the
world,
kind
of
all
bets
are
off.
Yeah.
You've
got
to
be
really
quite
defensive
at
the
edge
there's
also
limited
exposure
of
mappings.
A
So
the
key
thing
here
is:
you
want
to
only
expose
selective
endpoints
of
your
services
and
you
probably
have
different
sort
of
personas
working
at
the
edge
but
centralized
ops
kind
of
doing
sent,
sensible
ingress,
defaults
rate
limiting
or
these
kind
of
things.
And
then
you
have
say
product
teams
who
are
releasing
functionality,
maybe
shadowing
traffic,
maybe
canary,
launching
and
drip-feeding
traffic
into
new
services.
They
those
are
kind
of
two
distinct
personal
purpose
owners
within
the
north-south
kind
of
overall
persona.
A
If
you
like,
east-west,
very
dynamic,
as
Nick
pointed
out,
things
are
coming
up
going
down
all
the
time.
Your
east-west
kind
of
solution
has
to
bear
that
in
mind.
You
really
do
need
identity
and
things
like
MPLS
things
that
access
control
lists-
and
you
probably
saw
the
two
personas
here-
are
sane
in
same
defaults.
I've
actually
learned
this
from
Matt
Klein
I
know
the
Envoy
the
way
they
to
configure
envoy
lyft
by
default.
A
When
you
roll
it
out,
it
has
a
bunch
of
same
defaults
that
if
your
new
service
goes
crazy,
it
will
kind
of
get
contained
kind
of
get
quarantined,
which
I
thought
was
a
really
nice
way
to
handle
the
inevitable
mistakes
we
all
make.
When
you
know
you
start
making
lots
of
downstream
calls
or
tripping
circuit
breakers,
these
kind
of
things
the
service
mesh
can
prevent
some
of
the
damage
leaking
there.
But
the
way
you
configure
these
things
they
kind
of
the
requirements,
the
personas
involved.
I
think
at
the
moment
are
quite
different.
A
Hence
why
we
are
you
like
going
to
a
demo
with
ambassador
and
console
Connect,
but
sto
and
few
other
ones
are
trying
to
sort
of
marry
the
two
together
a
personal
opinion
at
the
moment.
I
do
think
the
use
cases
are
sufficiently
different
to
warrant
different
control
planes,
whether
you're
controlling
north-south
ingress
or
east-west
service
to
service,
but
I'd
love
to
hear
your
feedback
on
whether
you
think
that's
valid
or
not.
I'm
still,
learning
myself
on
this
one
I
think
that
is
time
for
the
demo
NIC
this
afternoon.
Awesome.
B
B
We
want
you
to
walk
away
with
a
solution,
so
I'm
going
to
quickly
show
you
how
we
can
use
console
Connect
service
mesh
with
the
Ambassador
API
gateway
to
create
and
to
end
TLS,
so
that
TLS
termination
at
CloudFlare
from
CloudFlare
through
to
our
edge
api
gateway
with
Ambassador
from
Ambassador
into
the
kubernetes
cluster
to
a
destination
service,
so
bare
with
me.
So
how
are
we
going
to
do
this?
B
So
one
of
the
things
that
we
we
need
to
do
is
we
do
need
to
install
console
and
we
need
to
install
Ambassador
I've
taken
some
artistic
liberties
in
that
I.
Don't
want
you
to
watch
me
struggle
to
do
that.
No
seriously,
it
takes
a
little
couple
of
minutes
for
that
sort
of
stuff
to
spin
up,
so
I
do
have
console
up
and
running
on
my
kubernetes
cluster
helm,
chart
helm,
install
console
and
I
do
have
my
Ambassador
API
gateway
installed.
B
Inside
of
of
kubernetes,
so
if
I
look
at
what's
involved
in
installing
Ambassador,
it's
a
Yama
file
or
helm
chart
I
can
literally
just
download
this
from
the
Ambassador
website
and
apply
it.
So
ambassador
uses
a
custom
CRD
to
be
able
to
allow
you
to
configure
the
various
different
rules
and
reliability
patterns
and
things
like
that.
It's
nothing
unusual,
it's
something
they
should
be
very
very
familiar
with.
It
has
obviously
some
are
back
in
order
for
the
the
custom
controller,
but
ultimately
it
then
has
the
Ambassador
complaint
control
plane,
which
configures
envoy
for
you.
B
B
So
we
are
gonna.
First
thing
we
want
to
do
once
we've
got
Ambassador
applied.
Is
we
need
to
make
some
configuration
so
there's
a
few
things
that
we
want
to
do
in
order
to
to
configure
ambassador
and
one
of
the
things
that
we
want
to
do?
Is
we
want
to
be
able
to
enable
the
the
console,
Connect
integration
so
again,
I'm
going
to
apply
another
kubernetes
set
of
resource
it?
B
That
allows
me
to
configure
Ambassador
to
interact
with
the
console
connect
service
mesh
once
you've
got
that
up
and
running
I
need
a
kubernetes
service,
so
just
a
load
balancer.
This
is
going
to
expose
my
my
public
endpoint,
pretty
standard
stuff.
Yet
again
we
we
do
have
some
of
the
Ambassador
annotations
and
that's
just
configuration
for
for
ambassador
where
things
get
interesting
is
that
I
need
to
be
able
to
configure
my
my
services
and
my
service
routes
so.
B
Thank
you.
So
we
can
see,
we've
got
those
roots
there.
We
don't
have
anything
running.
So
what
I
have
is
an
upstream
service
I
have
an
emoji
I
website
and
it's
our
demo
application,
and
that
has
an
API.
The
website
is
pure
react.js.
The
web.
The
API
is
just
a
goal
based
API
I
need
to
expose
both
of
those
to
the
Internet
and
I
need
to
do
it
securely.
B
So
with
Ambassador
how
to
expose
those
to
the
Internet
is
I
need
to
be
able
to
to
configure
the
routing
and
to
configure
the
routing.
I
can
use
the
Ambassador
CRD
so
I'm,
creating
a
mapping
resource
I'm
setting
my
prefix
of
slash.
So
that's
my
my
root.
Prefix
and
I
want
that
to
filter
on
a
host
header
of
a
modify
dot
today
that
allows
me
to
use
the
same
load
balancer
for
subdomains
or
different
domains,
and
I
want
to
map
it
to
a
service
inside
of
console.
B
B
Did
you
any
anybody,
go
to
see
the
SMI
presentation
the
other
night,
so
one
of
the
things
that
we've
we've
done
is
that
we've
we've
tried
to
make
all
of
that
configuration
easier.
So
what
I
want
to
be
able
to
do
is
I
want
to
be
kubernetes.
Centric
I
want
to
be
able
to
write
kubernetes
resources
to
be
able
to
configure
my
security
policy,
and
I
can
do
that
using
the
SMI
traffic
targets.
B
B
So
I'm
going
to
apply
those
intentions
and
those
intentions
are
going
to
just
be
that
that
mapping
so
I'm
gonna
do
that
with
the
SMI.
So
I
do
that
for
the
three
intentions
that
I
need:
I
need
to
explicitly
state
that
ambassador
is
allowed
to
talk
to
graph
on,
or
it's
allowed
to
talk
to
the
website
and
it's
allowed
to
talk
to
the
the
API
server.
B
Once
those
have
been
applied,
then
the
service
traffic
starts
to
flow.
So
you
go
from
that
denied
phase
which
you're
getting
here
from
this
just
sort
of
bad
error
to
a
situation
where
the
the
application
is
now
allowed
to
talk
to
the
traffic.
So
the
ank
ambassador,
API
gateway,
is
allowed
to
talk
to
the
upstream
services
and
we
can
see
that
it
works.
We're
going
to
do
a
quick,
a
quick
test
on
that.
B
B
Pretty
difficult
to
collect,
but
when
you
start
to
use
the
service
mesh,
one
of
the
things
that
service
mesh
gives
you
is
that
the
service
mesh
gives
you
access
to
those
statistics.
So
before
you
can
see
there,
everything
is
blue
because
I
didn't
have
any
traffic
which
is
allowed
to
flow,
but
I
can
start
seeing
the
metrics
around
my
ingress
service.
B
Now
everything
is
starting
to
to
go
green
I'm
gonna,
see
things
like
my
request,
counts
I'm,
going
to
see
my
API
request
times,
I'm,
getting
all
of
that
measurements
and
observability
and
I'm
getting
that
for
absolutely
free
I've
done
nothing
other
than
than
just
enable
the
service
mesh
and
again
I
know.
My
network
was
running
slow,
but
I
did
apply
that
SMI
policy
and
you
can
see
that
the
policy
is
all
there
now.
B
This
policy
is
that
gives
you
that
explicit
link
ambassador
at
the
edge
I
have
my
CloudFlare
origins
certificate,
so
I
have
absolute
no
gap.
Inside
of
any
of
that
request
flow
where
any
traffic
is
is
not
being
covered
by
TLS
process
termination,
CloudFlare,
TLS
cloud
fair,
makes
a
TLS
call
to
my
origin
server
again
using
the
the
specific
certificate
that
I've
configured
with
ambassador
ambassador
makes
em
TLS
authenticated
and
identified
calls
to
my
upstream
services.
A
So
if
you
do
want
to
play
with
this,
I
appreciate
something
it's
kind
of
hard
for,
along
with
sometimes
just
by
its
nature,
but
once
you've
got
at
sort
of
the
mental
model
like
is
it
definitely
quite,
as
you
said,
it's
quite
easy,
but
how
I
find
having
a
look
at
the
code
is
definitely
the
way
to
go
so
pop
along
to
github.
You
can
grab
that
and
the
kind
of
teal
the
ass
just
wrap
up
briefly
pretty
much
what
I
said
at
the
start.
A
We
are
seeing
this
kind
of
you
know
hybrid
sort
of
journey
way.
Moving
from
data
center
to
cloud
got
vm's
your
kubernetes
in
the
mix,
decoupling,
infrastructure
and
apps
is
a
good
thing,
but
you
do
need
to
do
it
incrementally
and
critically.
You
need
to
do
it
securely,
and
that
is
a
key
thing.
Nick
is
definitely
reminding
me
several
times
that
security
really
has
to
have
good
UX
and
like
with
SMI.
A
Let
Nick
was
demoing
they're
trying
to
make
these
things
as
easy
as
possible
to
apply
policies
within
like
the
actual
data
center
itself
within
the
east-west
traffic,
and
you
also
with
your
ingress,
have
convicted
to
find
various
sort
of
security
properties
there
to
defense-in-depth
is
vital.
Don't
forget
to
secure
your
apps
do
scan
your
dependencies.
Do
scan
your
ram.
Your
containers
yourself,
you're,
deploying,
but
don't
forget
about
the
network,
there's
a
lot
of
things
around
CI
CD
at
the
moment.
A
Continuous
delivery,
in
particular
for
scanning
all
your
components,
but
don't
forget
about
the
runtime
when
you
deploy
things,
make
sure
your
platform
is
secure
and
make
sure
the
coms
between
all
the
components
are
secure
too
and
do
mine
the
gaps.
It's
all
too
easy
in
systems
to
have
a
gap
where
TLS
is
being
terminated
and
it's
not
being
spun
up
until
further
down
or
further
upstream.
A
A
B
Stuff
Liz
rice
has
got
some
wonderful
talks
on
this,
but
even
if
I
break
into
an
application,
the
key
thing
is
what
you're
trying
to
do
is
stop
people
move
laterally.
You
do
that
in
a
number
of
ways.
The
first
is
you
secure
your
perimeters,
but
the
second:
is
you
secure
your
containers?
You
don't
allow
somebody
to
install
tools
or
download
binaries
that
they
can
then
use
to
further
exploits
zero
trust
is,
is
a
very,
very,
very
sort
of
broad
concept,
but
the
the
title
of
it
really
does
say
it
all.
B
A
Yeah
help
seems
not
coming
over
chat
to
us
after
this,
because
it's
a
very
deep
topic
of
anyone's
looking
to
more
information
to
read
on
this,
that
Google,
zero
trust
networks,
there's
a
fantastic
book
on
a
riling
about
this
and
there's
also
the
beyond
Corp
project
with
Google.
That's
well
worth
a
look
into
these
things,
but
basically,
as
Nick
said
that
the
title
is
self
descriptive
making
it
in
terms
of
trust,
no
one
there
is
literally
no
sort
of.
There
is
ZERO
trust
with
these
things
and
it's
a
good
question.
Thank
you.
Yeah
I.
B
Just
just
to
kind
of
end
on
that
as
well
that
you
can't
do
you
can't
cover
every
gap,
you
can't
stop
everything.
What
you
want
to
do
is
make
things
difficult,
make
it
as
difficult
as
possible
in
some
ways,
make
it
more
difficult
than
your
nearest
neighbor,
so
that
the
attacker
will
go
and
go
and
bother
them,
but
security
is,
is
incremental,
its
it
sort
of
covers
a
number
of
areas,
but
simple
techniques
like
network
security,
when
you
use
the
right
tooling
shouldn't
be
really
something
that
you
have
to
think
about.