►
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
Is Istio the Most Next Gen Next Gen Firewall Ever Created? - John Morello, Twistlock
Istio is emerging as a popular service mesh layer for cloud native apps and it delivers a variety of great features for devops scenarios. While security is one of its core tenets, Istio has far more potential than simply providing a secure wire transport between services. Its deep knowledge of the application layer, awareness of service concepts, and integrated service authentication mechanisms make it well suited for not just encrypting traffic flows but enforcing a least privilege connectivity model. In this session, we’ll talk about how putting all these capabilities together can result in a truly Next Gen NGFW that’s not just optimized for cloud native scenarios, but actually delivers better security because of them.
To learn more: https://sched.co/Grad
A
All
right
good
afternoon,
that's
loud,
it
is
3:40,
so
we'll
go
ahead
and
get
started
since
we
don't
have
a
tremendous
amount
of
time
for
the
session.
My
name
is
John
Morello
I'm,
the
CTO
at
twistlock,
how
many
the
guys
have
heard
of
twistlock
as
a
company
before
that
that
really
warms
my
heart
to
see
that
this
is
not
a
twistlock
presentation,
although
obviously
you
have
to
advertise
our
logo
and
pay
the
bills
and
so
forth.
A
But
this
is
actually
a
talk
on
sto,
but
it's
I
think
a
little
bit
of
a
different
sort
of
flavor
of
a
talk
about.
If
Co,
then
you
might
have
seen
before
my
background
is
very
much
in
security
and
and
crypto
or
just
like.
You
know,
kind
of
old-school
infrastructure
stuff
that
that's
no
longer
in
vogue.
But
what
this
talk
is
going
to
be
really
about
is
how
sto
provides
a
lot
of
capabilities
and
a
lot
of
opportunities.
A
I
guess
is
the
better
way
to
say
it
for
us
to
be
able
to
do
micro,
segmentation
and
firewalling
in
a
way,
that's
a
lot
more
relevant
to
the
modern
applications
that
you're
using
and
running.
Today,
but
also
actually
has
some
real,
clear
advantages
over
the
old
world
approach.
That
was
a
much
more
parameterize
duei
to
do
security
that
you
probably
still
have
and
still
operate
in
your
environment.
A
A
However,
there's
a
lot
of
really
relevant
things
that
delivers
as
a
software
firewall,
that
those
more
traditional,
proper
devices
so
to
speak,
historically
really
have
struggled
to
be
able
to
do
and
I
think
today
are
almost
impossible
for
them
to
be
able
to
do
for
effectively
and
then
we're
going
to
look
and
actually
look
at
what
an
is
to
enabled
environment
looks
like
we're
going
to
go
through
a
demo
at
the
end,
so
everybody
pray
to
pray
to
whatever
it
is
you
pray
to
that?
The
demo
works.
A
The
Internet
hasn't
been
great
here,
but
it's
a
fairly
straightforward
demo.
I
did
something
a
little
bit
interesting
for
the
demo
this
time,
in
that
the
sto
project
actually
has
a
really
great
set
of
docks,
and
example,
code
and
demos,
so
the
demo
we're
actually
gonna
do
is
actually
the
same
one
that
you
can
run
yourself
on
your
own
laptop
just
by
just
cloning,
the
repo
and
going
through
the
sample
stuff.
So
everything
we're
going
to
do
here
is
very
easy
for
you
to
replicate
in
your
own
world
as
well.
A
There's
been
this
notion
of
what's
called
a
next-gen
firewall,
that's
been
out
for
probably
quite
some
time
now,
maybe
at
least
a
decade
even-
and
it's
probably
the
worst
way
to
categorize
a
piece
of
technology
by
calling
it
next-gen,
because
you
almost
imply
there
that
it's
like
somehow
the
end
of
the
generation
like
it's
always
something
as
next-gen
right,
but
be
that
as
it
may
there.
There
is
an
actual
I
guess,
term
of
r2
term.
A
That
Gartner
and
other
analysts
use
that
refers
to
ng
WF
+
r/n
gfw,
rather
that
it's
specifically
about
a
set
of
capabilities.
That
basically
means
instead
of
the
traditional
firewall.
That
was.
You
know
more
primitive
view
that,
prior
to
next
generation,
traditional
firewalls
were
looking,
probably
at
mostly
layer,
2
layer,
3,
really
a
layer
3,
you
would
say
sorts
of
capabilities
here
to
be
able
to
say,
for
example,
like
this
IP
address,
can
talk
to
this
other
IP
address
on
this
specific
port
right.
That's
the
typical
model
that
you've
had
you
know.
A
A
The
application
providing
layer,
7
awareness
like
the
ability
to
not
just
say,
like
I'm
gonna,
allow
traffic
to
TCP
22
where
SSH
is
running,
but
I'm
gonna
also
be
able
to
filter
that
traffic
for
some
common
application
layer
attacks,
so
not
just
simply
looking
at
the
destination
port
and
protocol,
but
actually
looking
at
the
content
of
the
traffic.
That's
passing
through
that
as
well.
You
know
it's
similar
what
you're
familiar
with
already,
probably
as
a
wife,
although
typically
a
layer,
seven
capabilities
and
a
next-gen
firewall
or
broader
than
just
simply
HTTP
layer.
A
Seven
extra
firewalls
typically
also
had
some
kind
of
like
deep
Rimmer's,
ation
or
reaper
amortization
technologies.
Basically
the
notion
of
you
being
able
to
put
a
device
somewhere
within
your
data
center
and
to
be
able
to
route
traffic
through
that
device
to
zone
off
segments
of
that
data
center
from
each
other
to
create
some
kind
of
lease
privileged
networking
model-
or,
I
don't
say,
micro
segments,
the
7010
model,
but
at
least
a
segmented
model.
You
know
the
notion,
that's
that's
most
obvious,
of
course,
is
a
dmz,
but
you
know
there's
lots
of
other
ways.
A
You
can
take
that
and
do
that
a
more
fine-grain
way
than
just
simply
having
like
internet
facing
and
not
internet
facing
lots
of
organizations
will
have
something
where
they'll
have.
You
know,
management,
network
and
a
storage
network,
and
you
know
web
and
database
and
so
forth,
and
those
are
all
the
kinds
of
things
that
you
could
do
with
that.
The
typical
next-generation
firewalls,
but
they
were
being
managed
at
an
IP
layer.
You
know
you
were
assuming
that
those
entities
that
you
were
separating
had
some
kind
of
relatively
static
network
configuration.
A
You
know
they
had
a
certain
sort
of
IP
topology.
They
were
almost
always
gonna,
be
running
on
vm's
I
guess
you
know
perhaps
in
bare
metal,
but
all
this,
of
course
really
predates
the
rise
of
containers,
or
at
least
the
you
know,
containers
becoming
a
mainstream
sorta
technology.
So
because
of
that,
you
had
these
devices
that
that
had
assumed
that
the
ways
that
it
works,
routing
traffic
were
very
manual
and
had
a
very
clear
kind
of
path
that
they
would
follow.
A
You
know
like
traffic
was
going
to
route
from
from
this
virtual
LAN
or
this
network
interface
to
this
other
network
interface
on
this
set
of
protocols,
again
potentially
with
some
layer,
seven
awareness
that
that
it
puts
on
top
of
that.
Obviously,
the
applications,
though,
as
as
we've
evolved
as
an
industry,
the
primary
way
for
offering
applications
has
really
focused
around
utilizing
HTTP
as
kind
of
the
Universal
transport
right.
It
would
be
sort
of
weird
today.
A
It
provides
you
very
little
real
protection
today,
because
all
the
attacks
have
also
followed
the
applications
and
follow
the
the
infrastructure
to
be
something
that's
relevant
and
and
done
primarily
over
that
HTTP
port
I
kinda
have
a
joke
that
I
make
a
lot.
But
it's
really
true
that
HTTP
and
I
guess,
maybe
more
specifically.
Http
is
basically
the
universal
firewall
bypass
protocol
right.
A
The
earliest
that
I
can
remember
it
being
really
discussed
was
was
around
2003
or
so
with
a
initiative
that
was
referred
to
as
the
Jericho
forum,
but
basically
the
notion
there
was
instead
of
you
having
the
the
perimeter
approach,
like
the
perimeter,
only
approach
to
security.
What
a
lot
of
people
call
the
M&M.
A
Use
that
as
a
mechanism
to
make
sure
that
things
that
are
going
into
your
DMZ,
you
know
only
have
a
very
specific
level
of
access
to
your
your
database
VLAN
or
to
your
storage,
VLAN
or
whatever.
It
might
be
right.
So
this
concept
isn't
really
something
new
and
it's
kind
of
spun
out
into
some
other
ideas
that
are
related
to
it,
especially
the
notion
of
basically
being
able
to
you
know,
take
that
perimeter
and
not
just
dissolve
it
in
terms
of
way.
You
protect
the
applications,
but
also
even
the
way
that
you
access
those
applications.
A
You
know
for
those
of
you
guys
that
they're
working,
probably
a
more
modern
company
at
least
I
mean
you
just
I,
think
everybody
assumes
these
days
at
least
that
you
can
pretty
much
work
from
anywhere.
You
know
with
any
device
right
like
you
know,
especially
if
you're
a
young
company
or
a
company,
that's
really
embraced
a
lot
of
more
modern
IT
practices.
You
probably
can
you
know
open
your
laptop
or
open
any
laptop
and
connect
to
the
majority.
If
not,
you
know
the
entirety
of
the
applications
that
you
use.
A
Ization
has
kind
of
I
think
trained
people
to
expect
that
ability
to
connect
with
any
of
their
applications
from
anywhere
and
that
just
heightens
the
level
of
need
for
us
all
to
be
able
to
support
a
more
software
driven
way
of
connecting
applications
and
separating
applications
from
each
other.
It's
not
about
just
simply
in
use
or
access,
though
you
know,
like
we
talked
about
a
moment
ago.
It's
about
segmenting
off
the
different
pieces
of
your
data
center.
A
You
know,
I,
think
most
organizations,
if
you,
if
you
went
and
spoke
to
them
today
and
said
you
know
it's
important,
that
you
have
some
level
of
separation
and
zoning
of
your
networks.
I,
don't
think
you'd
really
get
hardly
anybody
that
would
disagree
with
that.
Conceptually
the
the
depth
or
the
lengths
I
guess
that
people
have
gone
into
to
actually
implement
acting
vary
quite
a
bit.
A
That's
bad
I
really
believe
in
and
I
think
it's
a
very
just
good
security
practices.
You
know
the
assumption
that
you
know
you're
always
going
to
have
compromises
in
your
environment
and
that
you
should
architect
your
environment
and
build
the
controls
there
to
help
contain
them
to
make
it
more
difficult
for
someone
that
compromises
some
application,
something
that
might
be
lower
privileged
from
being
able
to
get
access
to
something
that's
higher
privileged
and
as
those
applications
that
we're
all
building
are
transitioning
from.
A
You
know
physical
servers
or
SVM's,
at
least
transitioning
from
that
into
something
that's,
you
know
really
entirely
software-defined
with
kubernetes
and
containers.
Those
platforms
that
you
use
that
assume
that
you're
gonna
have
static,
addresses
and
VLANs
and
so
forth,
really
you're
not
able
to
protect.
You
I
mean
it's
possible,
you
could.
You
know
architect
something
and
go
through
a
whole
lot
of
effort,
and
you
know
a
whole
lot
of
pain
to
be
able
to
create
something
that
that
could
still
kind
of
flow
traffic
that
way.
A
But
if
you
think
about
the
way
that
kubernetes
are
really
most
of
any
of
these
technologies
that
that
that
are
out
there
work
for
interconnecting
these
micro
services,
it's
really
about
creating
a
big
flat
layer.
Three
sort
of
environment
right
and
that
bad
flat
layer,
three
environment,
that
you've
got
out
there
more
or
less
is,
is
opaque
to
mostly
existing
tools
that
you
have
right.
If
you're
taking
a
you
know,
if
you
have
a
span
port,
you
just
sort
of
mirror
traffic.
A
A
A
You
know
I
think
less
less
feasible,
less
less
you're,
less
able
to
be
able
to
configure
things
in
a
manual
basis
and
rely
on
assumptions
about
you
know
what
this
end
point
is
or
what
it's
you
know,
IP
address
might
be
or
things
of
that
nature
you
really
are
driven
the
only
way
that
you
can
practically
achieve
this
stuff.
It's
actually
rely
on
the
tools
to
have
a
security
to
Paula
G
that
actually
matches
and
is
continued
to
match,
with
overtime
automatically
through
the
orchestrator.
The
underlying
networking
topology,
that's
being
dynamically
managed
by
that
Orchestrator.
A
So
you
know
everything
in
this
environment
is
ephemeral.
Everything
is
constantly
changing
and
everything
is
really
constantly
moving
around
as
well
I
mean
you
don't
you
know,
you
don't
really
have
the
notion,
although
I
guess
you
technically
have
the
capability
to,
but
you
don't
really
have
the
notion
of
saying,
like
I,
want
to
run
this
one
particular
you
know
application
or
pod
or
service
or
whatnot
on
this
specific
node.
In
my
cluster
right
I
mean
you
can
do
some
affinities
and
things
of
that
nature,
but
I
mean
it's
kind
of
an
artificial
approach.
A
You
certainly
wouldn't
want
to
rely
on
things
like
that
to
control
the
way
that
you're
doing
networking
and
providing
segmentation
between
the
different
components,
your
application.
So
there's
a
lot
that
there's
a
few
things.
At
least
I
should
say
about
cloud
native
that
that
makes
this
actually
a
harder
problem
to
solve.
However,
I
think
it
also
really
and
more
importantly,
makes
it
an
easier
problem
to
solve,
as
well
as
long
as
you're
willing
to
embrace
the
tooling
and
embrace
a
more
modern
approach
to
doing
segmentation.
A
You
actually
have
a
better
toolset
and
a
more
autonomous
capability
to
do
this,
because
you're
really
transitioning
what
used
to
be
something
that
was
a
really
kind
of
device,
specific
configuration.
You
know
your
next-gen
firewall
or
even
your
you
know,
traditional
firewall.
If
you
wanted
to
config
that
device,
you
were
gonna,
make
an
SSH
connection
or
open.
A
Sto
provides
that
separation
of
traffic
that
makes
it
really
possible
for
you
to
do
a
lot
of
those
things
to
be
able
to
you
know.
So
it's
really
build
I,
think
on
top
of
that
baseline,
that
you
get
with
kubernetes
and
have
a
more
simplistic
way
of
achieving
some
of
those
goals,
but
probably
the
primary
thing
that
I
think
that
that
sto
provides
at
least
makes
more
feasible.
A
For
you
to
do
is
the
ability
to
provide
true,
like
into
in
network
base
crypto
the
ability
to
actually
guarantee
that
you
have
mutual
TLS,
that
you've
got
encrypted
connections
between
all
the
different
components.
Your
application,
without
you
having
to
worry
about
key
distribution
and
key
revocation
and
management
and
all
the
other
kind
of
overhead
that
goes
along
with
with
operating.
You
know
classical
kind
of
x.509
environments,
but
there's
a
lot
of
other
stuff
that
is
do
does
as
well.
A
So,
let's
take
a
very
basic
look
at
the
different
parts
of
isseo.
If
you're
looking
up
on
the
displace
here,
you
can
see
that
there's
really
kind
of
like
three
main
I
guess
aspects
to
the
sto
infrastructure.
So
to
speak,
the
the
guts
of
sto
itself
you've
got
pilot,
which
is
the
place,
that's
actually
managing
the
configuration
and
and
delivering
that
configuration
out
there
to
all
those
proxies
that's
running
across
the
environment,
the
proxy.
A
What
you
see
there
with
the
I
guess,
the
pinkish
purplish
color,
that's
envoy
proxy
is
what's
actually
responsible
for
routing
the
traffic
between
the
different
different
nodes
that
you've
got
within
the
environment
and
then
Citadel
is
the
component
that
actually
does
all
the
certificate
management
for
you,
if
you
guys
have
ever
dealt
with
operating
your
own
certificate
authority
and
if
you've
used
certificates
or
attempted
at
least
to
use
certificates
more
broadly
than
just
like
sticking
them
on
a
web
server
as
a
way
to
provide
TLS.
You
understand
the
pain,
that's
typically
involved
with
that.
A
You
know
unless
you
have
some
kind
of
of
certificate,
revocation
and
issuance
and
management
layer,
that's
on
top
of
that.
It's
really
tedious
and
difficult
to
provision
certs
out
there
to
everything
and
to
manage
those
over
time,
and
it
co
really
takes
a
huge
amount
of
that
effort.
Out
of
that,
for
you,
so
you
really
don't
have
to
even
think
about
it's
just
a
matter
of
turning
on
a
policy.
A
So
if
we
look
at
a
slide
of
a
policy
here
that
you
get
with
this
yo,
you
know
you've
got
this
deployment
policy.
That
that
is
is
a
simple.
You
know
ya
know
file.
It
makes
it
very
easy
to
declare
how
something
works,
but
that
that
simplicity.
You
know
you
shouldn't
look
at
the
simplicity
as
I
guess,
there's
a
detriment
or
something
that's
limiting,
because
as
employees
he's
actually
pretty
elegant
and
allows
you
to
make
something
that
used
to
be
very
complex,
to
be
able
to
state
relatively
easy
to
say
so.
A
Imagine
that
you
had
an
environment
where
you
had.
You
know
a
few
hundred
compute
nodes
where
you're
running
an
application
on
and
that
application
you
might
scale
it
out
to
running.
You
know
several
hundred
pods
or
something
across
that
environment.
If
you
wanted
to
have
a
model
where
you
said
like
the
front-end
component
of
my
application,
should
only
talk
to
the
cache
component
should
not
directly
talk
to
the
database
component.
If
you
don't
have
a
some
kind
of
layer
that
can
manage
that
and
that
you
can
declare
that
policy
in
this
simplistic
kind
of
manner.
A
Here,
where
you
can
say
you
know,
front-end
can
talk
to
cash,
but
front-end
cannot
talk
to
data
tier.
It's
really
hard
to
do
something
like
that.
I
would
argue
it's
just.
You
know
practically
really
impossible
to
do
something
like
that
and
that
the
aspect
of
this
that
is
do
really
makes,
makes
much
more
simplistic.
A
So
it's
it's
really
a
layer,
seven
aware
sort
of
embedded
distributed
firewall
if
you
will
in
a
way
that
that's
that's
more
powerful
I
think
then
a
lot
of
those
traditional
platforms
even
enabled
so
while
you're
not
like
looking
for
a
particular
like
you
know,
threat
signatures,
for
example,
like
you
might
think
of.
If
you
were
talking
about
a
kind
of
a
traditional
next-gen
firewall,
the
the
capabilities
that
you
have
are
actually
exceeding
what
you
had
in
most
of
those
cases,
because
now
you
no
longer
have
to
worry
about
routing
that
traffic.
A
You
just
simply
say
everywhere
that
this
application
runs
across
any
clout
across
any
infrastructure
that
it's
running
on.
I
always
want
to
make
sure
that
that
this
segmentation,
this
limited
lease
privilege
network
approach,
is
applicable
and
that
I've
got
a
way
to
authenticate
those
entities
between
each
other,
utilizing
that
TLS
or
we
say
the
certificates
that
are
issued
for
those
TLS
connections.
A
So
the
authentication
policy
is
kind
of
the
first
step.
I,
usually
always
describe
authentication
authorization
almost
as
a
as
a
two-step
process.
You
think
about
authenticating
authentication
is
about
who
you
are
right
to
be
able
to
say,
like
you
know,
I
am
this
identity,
and,
and
with
this
geo,
that
is
that
identity
is
really
application-specific
and
the
nice
thing
the
clean
thing
about
that
is
you
don't
have
to
manage
those
identities
like
in
some
kind
of
database.
It's
not
a
user
account.
A
A
One
you've
got
the
ability
to
authenticate.
You
know
who
you
are
the
next
step.
Is
you
know?
What
can
you
do
at
that
point?
So
by
default
is,
do
doesn't
have
authentication
or
treatment
doesn't
have
authorization
turn
on
it's
a
very
simple
thing
to
enable
we'll
do
that
as
part
of
the
demo,
but
authorization,
basically,
is
how
you're
able
to
say.
Okay,
now
that
I
know
who
you
are
and
again
who
being
the
application
I
can
say
what
you
can
do,
so
authorization
is
basically
being
able
to
say
these
are
kind
of
the
entitlements.
A
These
are
the
rights
the
privileges.
However,
you
want
to
phrase
it
that
this
component
of
your
application
has
and
again
getting
back
to
that
notion
that
we
talked
about
at
the
beginning
with
the
perimeter,
ization
or
reaper
immunization,
that
the
the
posture
that
you
want
to
drive
towards
is
those
application.
Components
should
have
the
minimal
amount
of
privilege
for
them
to
be
able
to
do
their
job,
no
more,
no
less
right.
A
You
can
literally
just
say
like
this
application:
identity
front-end
can
talk
to
cache
and
again
the
underlying
infrastructure
is
immaterial
to
you.
So
that's
really
I
mean
it's
really
quite
a
powerful
concept.
When
you
think
about
it
that
you
know
you
can
now
take
that
same
SEO
config,
and
you
can
run
that
in
Azure.
You
could
run
that
in
GCP.
You
can
run
it
on
premise.
You
can
run
on
your
own
laptop.
A
It
really
makes
no
difference
at
all,
no
matter
where
that's
running
you're
going
to
have
those
same
identities
that
same
ability
to
enforce
that
lease
privilege
network
model,
and
it's
all
done
in
software,
so
you
can
again
version
it.
You
control
it
and
get
you
can
make
it
part
of
the
CI
process
that
you
used
to
to
manage
that
CI
CD
process
use
to
manage
it.
A
There's
this
notion,
there's
kind
of
two
two
notions
and
I'm
bringing
this
up
now,
because
we'll
look
at
this
when
we
go
through
the
demo,
there's
two
real
notions
that
are
important,
that
when
you
define
these
policies,
the
notion
of
a
service
role
and
a
service
role
binding,
the
service
role
is
really
defining
like
that
kind
of
like
the
scope
of
authorization.
You
know
what
are
you?
What
are
you
authorized
to
do
as
part
of
this
service
role?
You
know
you
can
talk
to
this
entity.
A
A
That's
then
used
to
express
kind
of
the
end-to-end
flow,
so
a
service
role
is
simply
saying,
like
you
know,
something
that
would
that
would
have
this
service
role
is
entitled
to
be
able
to
do
these
activities
and
then
the
service
role
binding,
says
that
entitlement
plus
the
identity
of
which
is,
you
know
in
which
that
element
has
been
bestowed.
That's
the
service
role
binding
and
then
that's
how
you're
able
to
actually
the
adapt
component.
The
application
is
able
to
actually
go
out
and
do
whatever
task
that
it
performs.
A
So
it's
kind
of
a
two-step
process
and
instant,
it's
fairly
familiar
if
you're,
if
you're
familiar
with
services
who
service
roles
for
kubernetes
and
so
forth,
it's
a
very,
very
similar
kind
of
concept
that
you
that
you
have
here.
So
we
kind
of
covered
that
I
guess
I
got
a
bit
ahead
there,
but
one
thing
to
point
out
is
that
the
the
service
role
includes
that
that
permissions
section
you'll
actually
see
that
in
a
sample
authorization
policy.
Here
we're
actually
going
to
see
like
what
are
you
able
to
access
you
in
this
case?
A
I
can
access
this
product
service
and
you
can
see
the
methods
that
I
can
then
I
can
use
to
access
it.
So
you
know,
as
we
talked
about
earlier,
SVO
is
not
a
firewall
in
the
classical
sense
where
it's
or
a
layer,
3
fire
realities
in
the
classical
sense
where
it's
talking
about
IP
addresses.
You
know
there
there's
nothing
in
this
policy
that
refers
to
a
hostname
and
IP
address.
A
It's
simply
talking
about
these
primitives
that
are
much
more
relevant
to
you
as
a
developer,
or
at
least
as
a
you
know,
an
operator
that
has
nothing
to
do
with
the
underlying
IP
topology
of
the
network
on
which
this
runs.
But
we
do
have
the
ability
to
specify
some
kind
of
network
as
parameters,
at
least
by
being
able
to
say
where
are
the
HTTP
methods
that
it
can
use.
So
again,
this
is
a
very
simple
way
to
have
a
control
point
and
say
the
only
method.
A
You
know
if
I
have
an
application,
for
example,
that
is
serving
data,
but
not
consuming
data.
You
know,
I've
got
some
static
website
content
or
something
of
that
nature.
I
can
have
a
policy
that
only
will
allow
you
know
gets
it
will
allow
any
data
to
be
pushed
back
to
that
service
right.
So,
even
though
there's
connectivity
that's
allowed
there,
I
can
have
a
policy
that
restricts.
A
Everything
is
also
completely
api
enabled
and
the
reason
why
that's
cool
is
because
it
allows
products
and,
of
course,
I'll
I'll
plug
our
own
product,
but
a
lot
of
products
to
be
able
to
discover
that
topology
and
really
to
help
you
visualize
and
conceptualize.
What
that
security
model
looks
like
so
we'll
transition
now
and
actually
do
a
bit
of
a
demo
here,
but
I
want
to
start
off
with
this
demo.
So
what
I'm
going
to
be
going
through
when
we
go
through
the
demo
is
actually
the
the
authorization
lab
that's
on
the
SDO
site.
A
So
again
you
guys
can
just
clone
the
repo.
You
can
do
exactly
the
same
lab
that
we're
gonna
do
here
and
it's
lab
utilizes
this
this
bookstore
application.
So
it's
a
very
simplistic
app,
but
one
of
the
things
I
want
to
highlight
is
this:
application
is
composed
of
I,
don't
know
half
dozen
different
services
and
you
know
they
all
have
their
own
yeah
mall.
A
They
all
have
their
own
configuration
and,
if
you're
looking
simply
at
the
animal,
it's
really
difficult
to
figure
out
what's
actually
there,
but
one
of
the
things
that,
because
it's
ap
and
I
enabled
that
you
have
the
ability
to
do
is
to
have
software
that
can
learn
that
configuration
automatically
and
give
you
a
much
more
human,
understandable
way
to
browse
that
topology
and
to
ensure
that
you've
got
the
configuration
that
you
need
to
have
in
place.
So,
for
example,
this.
A
What
you're
looking
at
here
is
the
visual
representation
of
how
that
application
is
actually
deployed,
and
you
don't
have
to
come
in
and
you
know
and
instruct
the
application
like
in
this
case
twistlock
you
have
to
come
in
and
tell
us
like
you
know:
here's
the
configuration
or
you
have
to
upload
ya,
mole
and
so
forth.
You
literally
just
have
twistlock,
go
and
discover
via
the
the
the
SDO
control
plane.
A
What
is
that
topology
look
like,
and
then
you
can
build
this
map
where
you
can
actually
see
those
connections,
so
in
this
case
there's
actually
four
services
that
are
involved
one
service,
the
product
page
is
basically
the
front-end
for
it,
and
then
you
have
this
set
of
different
versions
of
a
review
service.
You
have
a
rating
service
and
then
you
have
this
info
info
details
and
when
you
put
all
that
together,
you
end
up
with
an
application
that
looks
like
this
visually,
so
you
can
see
here's
the
details,
here's
the
reviews,
the
ratings
I.
A
Think
if
I
refresh
the
page
you'll
see
that
you
get
some
stars
from
that.
So,
there's
multiple
different
services
that
are
involved
in
this
topology
and
if
I
look
at
you
know
this
application,
you
know
see
here.
Excuse
me,
I
can
see
if
I
click
on
sto
here
we
can
actually
learn
again
from
the
control
plane.
You
know
what
are
the
services
that
this
application
has
access
to?
What
are
the
methods
that
it
can
use?
So
you
can
really
understand
the
entirety
of
that
security.
A
The
book
store
application
again.
It's
composed
of
these
different
micro
services
and,
as
you
can
see
here,
when
I
refresh
the
app
you
can
see,
you
know
the
all.
The
micro
services
by
default
are
able
to
connect
to
each
other
and
talk
over
ISTE.
Oh,
this
is
just
a
normal
configuration,
but
what
we're
going
to
do
now
is
we're
actually
going
to
turn
on
some
of
the
functionality,
so
I'll
go
into
sto
here
and
we'll
just
simply
turn
on
and
look
at
the
let's
look
at
the
are
back
config
to
start
with.
A
So
once
we've
done
that
we
can
look
at
the
barback
config
again.
Actually,
let's
do
and
then
you
can
see
this
guy
now
in
our
back
configuration
so
once
our
back
is
turned
on,
you
have
to
declare,
or
you
have
to
configure
a
Co
to
allow
traffic
to
route
between
those
different
components.
So
right
now,
not
even
ingress
can
talk
to
that,
and
so
eventually
one
of
the
bad
things
about
this
demo
is,
it
doesn't
take
effect
immediately
so
probably
to
refresh
there.
We
go
finally
you'll
get
access
to
deny
there.
A
So
you
know,
obviously
you
don't
want
your
application
to
be
completely
cut
off
from
the
entire
world,
so
the
next
set
that
we'll
do
in
this
demo
is
actually
go
through
and
turn
on
an
sto
configuration
to
enable
the
ingress
controller
to
see
that
products
service
right.
So
let's
just
look
at
again
the
gamble
for
that,
as
we
were
looking
at
earlier,
we
define
you
know
the
service
role
that
we're
gonna
use,
and
so
you
can
see
the
service
role
here.
A
Is
the
product
page
service
we're
going
to
allow
it
to
be
accessed
with
a
get
method
and
we're
going
to
apply
that
to
star
which
includes
the
ingress
controller,
so
this
basically
is
going
to
expose
that
service
to
ingress,
and
this
will
allow
us
to
load
it
over
the
network.
So
if
we
come
here
and
we'll
apply,
it
and
I
need
to
figure
out
something
to
talk
to
you,
guys
about
or
say,
that'll
be
cool
and
distract
you
from
the
fact
that
it'll
take
a
little
while
for
this
to
load.
A
But
eventually,
what
will
happen
here
is
this
page
will
refresh
and
you'll
notice
that
you
can
see
that
the
the
application
but
you're
only
seeing
it
partially
work
right
and
what
are
we
missing
here?
We're
missing
details
and
we're
missing
reviews,
and
why
are
we
missing
that?
Because,
right
now,
the
only
thing
that's
available
is
the
ingress
that
you
can
see
here
to
product
page.
A
But
product
page
can't
talk
together
back
in
services
right
now,
and
so
you
can
see
is
we're
kind
of
building
up
from
a
no
privilege
model
to
a
I
guess
a
lease
privilege
model.
Let's
take
a
look
at
the
next
step
that
we'll
do
in
kind
of
the
last
step
that
we
have
in
the
demo
here
is
we're
going
to
enable
the
the
product
service
to
now
be
able
to
look
at
the
review
service
or
be
able
to
talk
to
the
review
service.
A
So
when
we
go
back
here,
let's
take
a
look
at
the
review
service,
so
you
can
see
here.
The
services
and
the
role
that
are
enabled
is
details
and
reviews.
Okay,
so
those
components
of
the
page
once
this
policy
is
applied
is
CEO
will
now
allow
that
traffic
to
route
in
these
those
components
of
the
page
will
load
and
we're
going
to
give
that
right
to
being
a
service
role
binding.
We're
give
that
right
to
the
products
page
all
right.
So
let's
go
here
and
and
apply
that.
A
Like
you
didn't
see
any
IP
address
right,
you
didn't
see
any
DNS
name,
it's
simply
just
saying,
like
those
identities
which
ISTE
automatically
manages
for
you,
those
identities
which
you
codify
access
for
in
a
combination
of
service
roles
and
service
role,
bindings
that
you
can
just
again
check
in
and
version
in
a
get
repo
that
enables
that
network
topology
that
that
really
next-gen
firewall
notion
of
deeper
memorization
and
lease
privilege.
Networking
to
now
follow
your
application,
irrespective
of
the
infrastructure
that
you're
running
it
on.
A
So,
just
to
summarize
and
wrap
the
session
up,
you
know,
micro
segmentation
is,
is
a
I
think
it
just
a
generally
recognized
as
a
good
thing
for
humanity
at
all.
But
it's
hard
to
do
with
traditional
tools
and
it's
it's
even
harder
to
do.
If
you're
trying
to
apply
traditional
tools
to
a
cloud
native,
topology
I
want
argued,
so
it's
like
functionally
impossible
for
you
to
use.
A
You
know
a
classical
sort
of
layer-3
approach
to
provide
micro
segmentation
in
an
environment
like
this,
without
going
through
a
whole
lot
of
artificial
effort
and
introducing
a
lot
of
fragility
of
things,
cloud
native
applications
making
both
both
more
difficult.
As
we
were
just
saying,
because
things
are
ephemeral
and
they're
changing,
and
you
know
you
don't
have
some
of
the
primitives
that
you
used
to
use
to
for
IP
addresses
and
ports
and
such,
but
also
makes
it
potentially
easier.
A
You
really
have
an
opportunity
now
to
be
able
to
do
security
in
a
much
more
scalable
way:
security,
with
it's
much
closer
to
your
application
security
that
really
takes
the
the
protection
that
you're
providing
and
decouples
it
from
the
underlying
network
infrastructure
and
now
attaches
it
to
the
app
so
it
flows
from
developer
environment
all
the
way
into
staging
and
whatever
clouds
and
whatever
environments
you
run
in-
and
this
is
all
stuff
you
can
use
today.
I
mean
this-
has
capabilities
that
you
have
now.