►
Description
Istio has many powerful security features for protecting your applications from malicious actors inside and outside of your network. Users rely on Istio features to meet various compliance standards designed for protection of sensitive data environments. These include encryption, authentication, authorization, monitoring tools, and control of ingress and egress traffic. Unfortunately, enabling and using these features is not as simple as clicking a checkbox. Configuring these policies correctly requires a deeper understanding of default behaviors, installation settings and the Istio CRDs. Failure to configure properly can result in data breaches or unintended behaviors. In this session, you will get an overview of the basics, out of the box functionality, and relevant Istio CRDs. In addition, you learn best practice guidelines for incrementally adopting these features and tools you can use to validate your security posture.
A
Hello,
my
name
is
ron
venom.
I
actually
just
joined
the
solo
team.
As
a
field
engineer,
I
come
from
ibm
where
I
was
a
technical
product
manager
and
a
developer
advocate
for
the
ibm
cloud
kubernetes
service
and
also
the
istio
related
offerings.
I
also
served
on
the
istio
steering
committee
for
a
couple
of
years.
A
So
in
this
talk,
I'm
hoping
to
provide
a
guide
to
adopting
the
security
features
of
istio.
I
think
it
will
be
a
mid
to
high
level
feature
overview
and
it
will
focus
on
how
to
adopt
the
features
without
breaking
everything.
It's
not
meant
to
be
a
deep
dive
session
on
any
one
thing,
so
just
basic
kubernetes
knowledge
is
kind
of
all.
A
Let's
talk
about
how
service-to-service
communication
happens
in
kubernetes,
kubernetes
has
an
abstraction
concept
called
the
service
where
a
group
of
same
or
pods
or
containers
can
get
a
dns
name
and
an
ip
address.
So
if
I
have
two
services,
let's
say
front
end
and
back
end
and
the
front
end
wants
to
talk
to
back
end
front
end
will
make
a
request
to
it's
the
backend's
dns
name,
maybe
http
slash.
You
know.
A
A
A
So
when
you
install
istio
and
enable
your
namespace
istio
will
first
automatically
inject
a
sidecar
proxy,
the
envoy
proxy,
to
run
next
to
all
of
your
containers.
It
runs
as
its
own
container
but
inside
the
same
kubernetes
pod.
So
these
proxies
are
then
programmed
to
intercept
all
incoming
and
outgoing
traffic.
A
Istio
extends
kubernetes
style
apis
using
crds,
so
you
can
just
create
your
istio
configuration
the
same
way.
You
create
your
kubernetes
configuration
and
apply
it
to
your
kubernetes.
Api
server
and
istio
will
take
that
configuration
and
then
convert
it
to
envoy
config
and
then
distribute
it
to
each
one
of
the
envoys
appropriately.
So
whatever
config
that
particular
envoy
needs,
istio
will
be
the
control,
plane
and
distribute
that
config.
A
So
now,
if
you
look
at
our
data
plane
traffic
now
when
front
end
wants
to
talk
to
the
back
end,
the
envoy
sidecar
will
actually
intercept
that
request
and
then
apply
any
configuration.
You
wanted
and
then
forward
it
on
and
the
same
thing
happens
on
the
back
inside
the
envoy
on
the
back
end
will
intercept
that
request.
A
You
know,
apply
any
configuration
policies
et
cetera
and
then
forward
it
on
to
back
in
and
now
the
beauty
of
it
is
that
this
communication
happens
without
any
changes
to
your
front
end
or
your
backend
container,
and
this
programmable
network
is
called
the
service
mesh.
So
you
can
do
things
like
canary
deployments
or
a
b
testing,
so
you
can
roll
out
a
new
version
of
your
application
and
send
percentage
of
your
traffic
to
it
or
header.
Based
routing
to
that
new
version,
you
can
implement
hardening
features
like
weight,
limiting
circuit
breaking
retries.
A
You
can
inject
faults
into
the
system
to
see
how
the
rest
of
your
system
behaves.
You
can
enforce
policies,
get
telemetry
information
about.
You
know
everything
that's
going
on
in
your
in
your
mesh
and
last
but
not
least,
you
have
much
more
security
controls
and
that's
what
we're
going
to
be
talking
about
today.
A
A
These
gateways
are
used
for
incoming
traffic
into
your
cluster
or
into
your
mesh
or
and
also
outgoing
traffic
as
well.
So
you
can
get
the
same
functionality
that
you're
getting
with
your
service
to
service
proxies,
as
also
you
can
get
that
same
functionality
with
traffic
coming
in
and
out
of
your
cluster
okay,
so
you've
installed
sdo.
You
kind
of
played
with
the
getting
started,
and
now
what
so?
First,
let's
get
control
over
your
outbound
traffic
right.
A
A
A
So
in
this
example,
if
you're
seeing
this
this
line
going
through
this
pass-through
cluster,
this
means
that
your
application,
that
one
container
that
ratings
container
is
is
talking
to
some
external
service.
That
istio
doesn't
know
about.
The
word.
Pass-Through
cluster
is
the
name
of
a
generic
virtual
envoy
cluster
that
is
created
by
istio
to
capture
all
this
outbound
traffic,
and
you
can
categorize
it
and
give
metrics
about
it.
So
this
is
a
good
way
to
find
out
which
one
of
your
pods,
which
one
of
your
applications,
is
talking
to
an
external
service.
A
So
next
you
want
to
get
details
about
what
this
external
service
is,
and
for
that
you
can
use
prometheus
with
istio
each
one
of
the
envoy
proxies
exposes
metrics
about
the
traffic
that's
coming
in
and
out.
So
if
you
search
for
these
two
queries,
you
know
you're,
basically,
looking
for
you
know,
destination
being
passed
through
clusters,
then
you
can
get
this
information
about
all
the
pods
that
are
part
of
the
mesh.
A
A
As
you
can
see
you
can,
you
know
tell
like
which
of
your
container
is
making
the
request,
which
one
of
your
pod
is
making
the
request
I
should
say,
and
and
who
is
it,
who
it's
making
the
request
to?
In
this
example,
it's
making
a
request
to
httpbin.org
and
in
the
bottom
example,
it's
it's
tcp,
so
you
don't
have
that
http
information,
but
you
can
still
see
where
that
request
is
coming
from
and,
if
you
add
some
custom
labels
to
your
to
your
prometheus,
metrics
and
add
destination
ip.
A
A
If
you
don't
have
like
prometheus
set
up
and
or
you
just
want
to
look
at,
you
know
one
your
one
pod,
you
can
just
enable
istio
access
logging
and
then
check
logs
on
a
per
pod
basis.
So
if
you
have
some
kind
of
log
aggregation
service,
then
obviously
you
can
quickly
pull
the
logs
from
all
of
your
pods.
If
not,
you
can,
just
you
know,
run
cube.
A
A
So
once
you
have
your
once,
you
know
all
of
your
external
endpoints.
You
can
start
telling
istio
about
them,
you're,
basically
just
adding
it
to
the
istios,
like
service
registry,
I'm
showing
a
simple
example
of
declaring
an
endpoint
for
httpbin.org
on
port
80.,
so
it's
just
standard
http
httpbin.org
and
then
I'm
telling
istio
to
do
the
dns
resolution.
A
Once
you
have
that
service
entry
defined,
you
can
run
the
istio
ctl
proxy
config
endpoints
command
and
and
point
it
at
at
a
given
pod,
and
then
you
can
see
all
the
new
endpoints
that
were
added.
So
these
are
basically
all
the
end
points
that
now
istio
knows
about
that
can
route
that
it
can
route
to
from
that
particular
pod.
A
You
can
tell
istio
to
not
send
traffic
to
it
and
to
do
that,
you
have
to
change
this
installation
flag,
called
outbound
traffic
policy
by
default.
It's
set
to
allow
any
and
you're
going
to
change
that
to
registry
only
and
then
that
immediately
starts
blocking
requests
to
end
points
that
are
not
that
that
istio
doesn't
know
about
that,
that
there's
no
service
entry
for
and
and
that's
it
I
mean-
then
you
look
at
kiali.
A
A
A
You
know
a
set
of
ip
ranges
or
a
set
of
ports
that
you
can
just
tell
envoy
to
just
ignore,
and
these
these
annotations
are
useful
when
you
can't
get
your
application
to
work
with
the
proxy
for
some
reason,
and
you
just
want
to
bypass
it
and
talk
directly
to
it,
but
from
like
a
security
enforcement
perspective,
you
know.
That's,
that's,
that's
not
useful!
You
can't.
You
can't
trust
your
developers
to
not
use
this
annotation
and
just
kind
of
get
around
it.
A
This
type
of
control
is
like
is
a
key
requirement
for
financial
applications
and
meeting
compliance
requirements
check
out
the
the
two
links
I
have
shared
below
the
first
one
talks
about.
You
know
how
to
set
up
this
egress
gateway
and
then
direct
traffic
from
your
application
file
to
the
egress
gateway
and
then
from
the
egress
gateway
out
to
the
world,
and
then
the
second
blog
talks
more
about.
You
know
why
you
would
want
to
do
this,
especially
for
for
compliance
reasons.
A
The
next
topic
is
around
traffic
encryption,
so
there's
two
main
reasons
to
to
do:
traffic
encryptions,
you
know
one,
you
know
protect
your
data
against
any
like
network
like
packet,
sniffing
or
or
doing
like,
like
a
man
in
the
middle
attack,
and
the
second
is
to
protect
against,
like
a
malicious,
a
user
or
or
an
application
trying
to
impersonate
a
service
in
order
to
to
receive
receive
traffic
to
divert
traffic
from
where
it's
supposed
to
go.
Instead,
you
know
it's
intercepting
that
traffic.
A
A
A
Once
the
envoy
starts
up
in
that
pod,
it
will
get
that
certificate
from
from
the
istio
agent.
That's
that's
signed,
and
then
it
uses
this
certificate
as
its
as
its
identity.
Its
identity
is
now
embedded
inside
of
the
certificate
to
view
basic
information
about
this
x509
certificate.
You
can
launch
the
envoy
dashboard.
A
A
What
that
means
is
when
one
mesh
workload
is
talking
to
another
mesh
workload.
Basically,
if
they
both
have
sidecars
istio
automatically
programs,
the
calling
workload
to
encrypt
the
traffic,
so
you
so
it
knows
that
you
know
there's
two
workloads
that
can
do
mutual
tls,
so
it'll
start
doing
it'll
start
doing
that,
but
when
workloads
are
not
part
of
the
mesh
and
they're
calling
your
workload
that
are
part
of
the
mesh,
so
basically
when
you're
incrementally
adopting
it.
A
We
want
to
allow
this
this
connection
this
this
plain
text
connection,
so
so
in
order
to
allow
this
graceful
adoption
of
istio
mtls
by
default.
The
policy
that's
set
on
the
the
workload
is
to
allow
both
plain
text
and
mutual
tls.
So
when
it
comes
to
policy
the
rule
that
is
enforced
on
the
server
side
in
this
example,
it's
the
back
end.
The
default
policy
is
to
allow
both
plaintext
and
mutual
pls.
A
So
that's
great
when
you're
onboarding
your
applications,
one
at
a
time,
but
when
you're
done
doing
that,
when
all
your
applications
are
part
of
the
mesh,
then
you
need
to
switch
this
from
permissive
mode
to
strict,
and
this
tells
envoy
on
on
the
server
side
or
in
this
case
in
the
back
inside,
to
only
accept
mtls
connections.
So
I'm
showing
a
simple
global
policy
here
that
says
I
want
strict
mutual
tls
everywhere
in
my
mesh,
but
this
can
be
done
at
a
namespace
level.
A
It
could
be
done
per
workload
using
selector
labels
or
or
actually
even
by
port
you
can.
You
can
set
strict
mutual
policy
for
a
particular
workload
except
a
particular
port,
which
you
can
deny
that's
usually
helpful
when
you
have
some
kind
of
like
metrics
endpoint
that
you
don't
or
can't
have
mutual
tls
on,
so
you
can
just
disable
it
just
for
that
one
port
using
this
pure
authentication
policy
and
then
once
you've
done
that
to
verify
you
can
use
kiali
to
observe
the
traffic
flow.
A
Now,
if
you
look
closely
on
top
of
each
one
of
those
arrows,
there's
a
there's,
a
lock
icon
that
that
shows
you.
If
all
the
traffic
that's
going
between
these
two
is
as
mutual
tls
to
see
this
lock
icon.
You
will
have
to
click
on
that
display,
drop
down
and
click
on
security,
and
then,
once
you
see
the
lock
icon,
you
should
be
able
to
click
on
the
arrow
or
the
icon
and
then
get
more
information
about
the
calling
and
then
the
where
the
workload's
being
called
to.
A
A
A
Another
way
you
can
check
to
see
if,
if
it's
using
a
mutual
tls
is
to
check
for
the
listeners
on
the
proxy.
So
if
you
use
istio,
ctrl
proxyconfig,
listener
command
and
point
it
at
a
particular
pod,
you
can
see
what
network
locations
the
envoy
is
exposing
to
its
downstream
clients.
So
when
you
have
permissive
mode,
the
top
example
you
can
see
that
it's
listening
for
tls,
plain
text
and
raw
buffer
traffic
on
port
9080,
but
when
you
have
strict
mode
enabled
it's
only
listening
on
tls,
as
shown
in
the
bottom
example.
A
The
main
reason
I've
seen
that
people
are
adopting
istio
is
to
reach
these
compliance
requirements.
So
you
know
being
able
to
prove
that
they've
they've
met.
That
requirement
is
very
important,
so
they
need
multiple
ways
of
kind
of
showing
this.
This
data
there
are
actually
plenty
of
other
ways
using
metrics,
etc.
That
you
can.
A
A
A
These
policies
are
applied
on
the
the
server
workload,
so
in
this
case
it
would
be
the
database
service
and
they
operate
on
a
layer,
seven
level,
meaning
that
they
can
introspect
the
request.
They
can
understand
that
it's
that
it's
an
http
request.
They
can
introspect
it
and
they
can
make
decisions
based
on
the
contents
of
that
request
and
they're
pretty
straightforward.
A
You
can
specify
the
workload
that
you
want
to
apply.
This
particular
authorization
policy
too.
By
using
selector
labels,
you
can
make
allow
and
deny
policies
by
default.
Everything
is
allowed,
but
if
you
have
an
allow
policy
on
a
particular
workload
and
it
matches,
then
only
allows
those
requests
and
if
there's
a
deny
policies
that
match,
then
it
then
obviously
it
doesn't
allow
that
traffic.
It's
very
it's
intuitive.
Once
you
start
using
it,
you
can
optionally
specify
a
from
to
to
declare.
You
know
where
that
request
is
coming
from.
A
A
A
Again,
when
you're
starting
to
write
your
authorization
policies
to
know
which,
what
policies
to
write
you
can
leverage
your
access
logs
access
logs,
show
information
about
traffic
coming
in
as
well
as
going
out.
So
in
this
example,
we're
showing
that
you
know
traffic
is
coming
in
on
an
inbound
request.
You
can
see
the
ip
address
that
it's
coming
in
on
it's
making
a
post
request
to
the
slash
review,
so
you
can
see
the
method
and
the
path,
so
you
can
use
these
access
log
entries
to
start
building
out
your
your
authorization
policies.
A
Once
you
think,
you've
created
them
all
and
let's
say
your
application
is
not
working.
You
will
need
to
start
debugging
one
easy
check
to
see
if
it's
your
authorization
policies,
that's
that's
causing
your
application
to
break
is
to
look
at
the
response
body.
If
you're
seeing
our
back
access
denied,
as
I'm
shown
in
the
first
screenshot
here,
then
it's
most
likely
an
authorization
policy.
That's
blocking
it.
A
Next
I'll
cover
request,
authentication.
This
is
for
defining
what
request.
Authentication
methods
are
supported
by
a
workload,
so
it
lets
you
configure
like
job
policies
so
that
envoy
can
check
to
see
if
a
valid
token
or
valid
authentication
is
there
on
the
request
before
sending
it
out
to
your
workload.
A
So
this
is
a
simple
example
here.
That's
saying
that
for
my
orders
workload
it
requires
a
valid
jot
token.
That's
issued
by
you
know:
provider
the
the
issuer
is
example
dash
provider,
and
then
it
also
specifies
the
url
of
the
public
key
that
it's
going
to
use
for
that
job,
key
validation,
and
this
alone.
This
policy
alone
will
cause
istio
to
do
the
validation,
if,
if
the
token
is
present,
but
if
it
doesn't
have
any
any
auth
credentials
right.
If
there's
no
token,
then
it
will
still
allow
the
request.
A
A
The
three
things
that
you
should
look
into
are
timeouts
circuit,
breaking
and
rate.
Limiting
timeouts
are
pretty
easy
to
set
in
sdo,
and
this
example
is
showing
that
for
the
review
service,
you
want
to
set
a
timeout
value
of
a
half.
A
second
see
it's
you
know
very
straightforward
and
timeouts
are
important
in
order
to
avoid
like
cascading
failures
in
your
microservices
to
test
it
out,
you
can
leverage
istio's
fault
injection
features
to
test
that
your
timeouts
are
working
properly
for
next
is
circuit.
A
Breaking
circuit
breaking
is
a
little
more
complicated
to
configure
properly
because
it
like
it
really
kind
of
depends
on
like
what
your
application
can
handle.
So
you
need
a
better
understanding
of
like
what
kind
of
requests
your
application
you
know
is
expecting
to
receive
how
long
each
request
is
going
to
take.
You
know
what
is
a
valid.
You
know
error.
How
many
times
of
an
error
can
happen
before
you
declare
that
the
service
is
should
be
taking
out
of
rotation?
A
So
you
need
to
understand
your
application
a
little
bit
more
before
you
can
start
writing
good
circuit
breaking
policies,
but
when
you
do,
you
can
set
things
like
maximum
number
of
connections.
Maximum,
pending
requests,
requests
for
connections
number
of
consecutive
errors
before
taking
out
of
before
marking
it
as
unhealthy
and
ejecting
it.
How
long
before,
bringing
it
back
into
rotation.