►
Description
With Hybrid Cloud adoption, an organization's workload increases by using on-premises Virtual Machines, public cloud Virtual machines and containers. This increase of "Surface" presents a new challenge to protect the digital assets from bad actors. Modern organizations have shifted their strategy from "if a breach will happen" to "when a breach will occur". When a breach is discovered, the best option is to contain the breach radius. Microsegmentation is where organizations turn to prevent breaches from spreading like wildfire. Palo Alto has taken a unique approach to microsegmentation. while allowing the customer the freedom to cloud compute, build cloud native apps, and increase deployment velocity. In today's session, we will learn about Palo Alto's unique way of approaching segmentation and learn about some of the new trends in the industry.
Twitch: https://red.ht/twitch
A
A
B
Good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
another
devsecops
is
the
way
here
on
red
hat,
live
streaming,
I'm
chris
short
host
and
show
runner
of
red
hat
live
streaming,
I'm
joined
by
the
one
and
only
dave,
muir
dave.
How
are
things
in
your
neck
of
the
woods
today.
B
C
In
florida,
yeah,
that's
true:
we've
had
a
couple
skirts
of
some
tropical
storms,
you
know
good
old,
frank
or
fred,
whatever
his
name
was
and
then
and
then
grace
and
but
we're
doing
good
down
here
so
yeah
good
stuff,
we've
got
a
great
show
today.
I
think
for
everyone
this
is
obviously
part
of
our
devsecops
is
the
way
series
that
we
do
monthly
august
can't
believe
it's
already
august
right.
C
You
always
say
that,
but
august
is
network
controls
month
and
got
some
great
guests
who
better
to
talk
about
network
controls
than
people
from
a
company
that
has
network
in
the
name
right
so
I'll,
let
them
I'll
let
them
introduce
themselves
here
in
a
second,
but
before
I
do
just
wanted
to
talk
about
our
series
really
quick
for
those
of
you
that
don't
know
we
do
a
monthly
series.
We
actually
have
two
red
hat
live
streaming
shows.
C
This
is
one
that's
more
on
sort
of
thought
leadership
and
about
that
topic
that
we're
talking
about
that
month,
and
then
we
also
have
a
second
one.
That's
aligned
to
the
openshift
commons
briefing
operator
hours
show
that
we
feature
partner
technology
alongside
red
hat
and
you
can
see
the
the
months.
We've
got
a
couple
months
more
to
go
in
terms
of
the
topics.
C
This
all
relates
to
a
framework
that
red
hat
has
created
around
devsecops
with
all
these
different
categories,
and
we've
got
different
functions
that
tie
to
those
categories
and
how
you
plot
those
features
and
functions
to
a
to
a
devops
life
cycle,
but
we
also
do
podcasts.
We
try
to
publish
a
couple
blogs
every
month
on
that
topic,
so
to
find
out
more.
You
can
see.
C
So
I
think
that's
it
for
the
intro.
For
today
we're
gonna
talk
a
lot
about
networks
and
micro
segmentation.
We
might
throw
at
a
buzzword
here
there
too,
like
xero
trust,
which
is
one
of
my
recent
favorite
ones,
and
then
we'll
do
some
demos
to
show
some
of
that
stuff.
So
I
think
it's
going
to
be
a
good
session.
C
D
Sure
hi
everybody
virtually,
I
suppose
my
name
is
oracle
of
products
at
politics,
part
of
the
prismacloud
team.
Actually,
I
joined
palo
alto
networks
through
an
acquisition
of
a
company
called
apparetto
and
we're
going
to
talk
about
the
technology
that
we
built
at
apparato,
which
is
now
part
of
prismacloud,
alex,
go
ahead.
E
C
E
E
Last
week
right,
it
was
really
cold,
almost
zero
degrees
celsius,
which
I
have
no
way
to
measure
fahrenheit's,
not
can't
work
my
way
around
between
celsius
and
fahrenheit,
sorry
guys,
but
it
was
pretty
cold
and
right
now,
it's
probably
a
very
warm
day
we
had
in
the
last
probably
three
or
four
weeks.
It's
around
30
celsius.
D
C
D
D
Yeah,
so
you
know
we
were
a
startup
that
we
got
acquired
end
of
2019
our
we
joined
palo
alto
networks,
officially
january
of
2020
and
yeah.
So
we
we
we're
essentially
building
a
network
segmentation
solution
and
that's
very
different
from
sort
of
what
was
available
out
there
and
and
that
sort
of
goes
into
sort
of
the
impetus
of
behind
apparato.
What
you
know,
why
was
apparatus
started
and
what
what
were
you
trying
to
achieve?
D
So
the
founders
come
from
a
very
you
know:
network
security,
focused
action,
network,
infrastructure-focused
background
and
one
of
their
realization.
Having
worked
at
you
know,
large
networking
companies
has
been
security
specifically
network
security
has
always
been
tied
to
the
underlying
network
infrastructure,
but
the
shift
to
cloud
is
making
that
it.
It
creates,
makes
it
very
difficult
if
you
tie
it
to
the
underlying
network
infrastructure
because
a
you
don't
own.
The
network
infrastructure
in
the
cloud
you're
using
somebody
else's
network
infrastructure,
and
it
could
be.
D
D
Something
is
sitting
in
an
auto
scaling
group
sitting
behind
a
load
balancer
and
it's
you
know
as
you're
scaling
your
application.
It's
automatically
scaling
and
new
ips
are
getting
allocated
so
relying
on
ip
based
mechanisms
to
solve
a
network
segmentation
problem,
their
thesis
was,
is
just
not
going
to
work
for
the
future
and
he
needs
to
rely
on
something
much
more
application-centric,
much
more
workload-centric
and
that's
what
we
called
workload
identity
right.
C
E
E
C
Awesome
well
good
stuff,
so
ari,
if
you
mentioned
you
know
obviously
micro
segmentation
and
palo
alto
networks,
I'm
assuming
palo
alto,
looked
at
the
market
and
said
wow,
you
know
kubernetes
cloud.
This
is
going
to
be
a
tough
problem
to
solve
and
hence
why
they
looked
at
apparetto
for
that
purchase.
Is
that
how
sort
of
transpired
or
sure
there
was
more
to
that.
D
Oh
yeah,
I
mean
there
are
lots
of
stuff
in
the
back
end,
but
yeah.
I
think
you
summarized
it
very
well
in
terms
of
recognition
from
nir
and
lee
and
nikesh
that
that
the
transition
to
cloud
and
transition
to
kubernetes
essentially
requires
us
to
rethink
about
a
problem
like
network
segmentation
and
market
segmentation
right,
and
how
do
we
kind
of
solve
that
problem
specifically
for
these
cloud
native
types
of
environments?
Absolutely
that
was
impetus
behind
the
entire
discussion
and
and
yeah.
C
C
Yeah
yeah
and
so
yeah.
I
can
imagine
they're
very
well
obviously
in
the
legacy
type
network
controls
but
as
kubernetes
has
been
gaining,
you
know
popularity,
it's
a
whole
different
bottleneck,
so
I
mean
you
can't
imagine,
as
you
mentioned
just
thinking
about
infrastructure
and
controlling
that,
and
if
that,
if
your
network,
you
know
strategy
is
tied
to
infrastructure,
you're,
never
going
to
get
very
far
with
kubernetes
right.
D
C
D
D
There
is
no,
as
we
say
in
security,
there's
no
silver
bullet,
you
buy
one
product
and
you
get
everything.
That's
you
have
to
kind
of
think
about
it
with
defense
in
depth.
Right
so
obviously,
prismacloud
is
a
platform.
Has
you
know,
visibility,
compliance
and
governance
capabilities
cloud
workload
protection?
You
know.
D
Even
we
just
recently
announced
identity
access
management
for
permissions
management
for
cloud
assets
made
an
acquisition
around
shift
security
and
the
bucket
that
we're
in
is
cloud
network
security
specifically
focused
on
network
security,
for
cloud
right
and
that's
the
overall
strategy
for
us.
We
have
various
pillars.
We
call-
and
you
know
our
focus
with
apparato-
is
the
cloud
network
security
bucket
bringing
in
the
micro
simulation
technology
yeah.
C
D
No,
I
look
yeah.
We
definitely
from
my
experience,
definitely
sort
of
gathered
some
of
the
critical
things
that
customers
what
I
see
customers
require.
I
think,
first
and
foremost,
you
know
you
can't
segment
what
you
don't
know.
You
have
right.
That's
the
first
thing
that
we
always
hear
from
customers
as
they
begin
their
segmentation
journey,
which
can
be
for
many
reasons
right.
It
could
be
compliance,
governance,
making
sure
they
protect
their
ip
there's
lots
of
drivers
for
network
segmentation.
D
But,
coming
back
to
the
point,
you
can't
segment
what
you
can't
see,
so
visibility
is
obviously
the
first
step
and
in
fact,
most
customers
start
their
journey
towards
network
segmentation
with
visibility.
Only
no
enforcement
of
controls,
no
enforcement,
so
essentially
being
able
to
get
that
very
quickly
be
able
to
deploy.
You
know
the
technologies
agent,
based
as
in
most
of
the
technologies
in
this
space,
are
agent-based,
be
able
to
deploy
these
agents
very
quickly
and
get
that
visibility.
D
And
the
second
thing
that
I
you
know
that
I
also
came
to
the
recognition
that,
having
talked
to
a
lot
of
customers
and
operationalized
this
technology
is
you
want
to
segment,
but
at
the
same
time
you
have
to
do
it
in
a
way
that
it
fits
to.
It
fits
into
workflows
that
cloud
people
are
familiar
with
devops
nuclear
familiar
with,
and
what
I
mean
by
that
is
you?
Don't?
We've
had
an
inclination
to
rely
on
centralized
ticketing
systems
quite
a
bit
in
the
networking
industry
I
want
to
be
able
to.
D
So
you
have
the
right
guard
rails
that
centralized
security
teams
can
set
up,
and
then
you
give
some
ownership
to
your
devops
teams
and
your
application
owners
with
the
visibility
combined
with
that
visibility
for
them
to
write
their
own
sets
of
rules
as
long
as
it
stays
within
the
guardrails.
You
don't
have
this
problem
of.
I
want
to
deploy
an
application.
I
launched
something
new
in
my
stack
and
now
I
need
to
open
up
a
ticket.
I
can
define
that
as
code
and
it
can
be
part
of
my
application
deployment
pipeline
right
yeah.
D
C
A
C
I
mentioned
a
buzzword
earlier,
zero
trust
and
actually
it's
something
that
I've
been
hearing
now
on
a
daily
basis.
It's
a
real
thing
right,
it's
not
just
a
marketing
buzz
word,
but
but
I'd
say
a
year
ago
I
didn't
hear
it
as
often,
maybe
not
at
all,
so
why?
Why
do
you
think
we're
hearing
zero
trust?
D
You've
got
users
and
you've
got
devices
devices
being
iot
devices
right
and
if
you
can
solve
an
access
control
problem
between
these
three
things,
what
you
know
devices
apps
talking
to
devices
talking
to
apps
users,
talking
to
apps
or
apps
talking
to
apps
right,
you
can
solve
this
probabilistically
across
your
enterprise.
You've
really
solved
a
lot
of
problems
and
with
zero
trust.
The
assumption
is,
the
underlying
network.
Infrastructure
is
untrusted
and
you
want
to
rely
on
end-to-end
authentication
mechanisms
really
figure
out
who
are?
Who
is
this?
D
You
know
asset,
be
it
a
user
or
an
application,
trying
to
talk
to
something
else.
Right,
and
I
mean
zero
trust
in
my
opinion-
is
sort
of
a
natural
shift
in
the
security
industry.
I
think
it
has
multiple
facets.
It's
not
just
on
the
networking
side.
You'll
talk
you
hear
about
you
know:
identity
players
like
octa
ping,
odds,
zero.
Now
talk
about
zero
trust,
you'll
hear
about
you,
know:
vpn
replacements,
with
zero
trust
right.
So
there's
a
lot
of
aspects
in
the
zero
trust
industry,
and
it
all
boils
down
to.
D
You
know,
really
identify
the
two
endpoints
you
know
assume
the
underlying
network
infrastructure
is
untrusted
and
be
able
to
authenticate
trust
but
verify
both
those
endpoints
before
allowing
that
communication
right
and
that's
really
how
we
think
about
it,
and-
and
I
just
answer
your
question-
how
I
think
the
industry
is
evolving
right
and
one
more
example
I'll
give
you,
and
I
always
think
this
is
a
nice
way
to
kind
of
think
about
zero
trust
like
it.
You
know,
we've
been
in
the
it
industry
for
some
time
now.
D
You
know
ten
years
ago,
when
you
logged
into
your
corporate
application,
very
common
for
us
to
vpn
in
and
essentially
assume
that
hey,
I
came
into
a
part
of
the
iip
space
and
I
should
be
allowed
to
this
application
right
now
with
you
know
you
asked
like
why
is
this
even
more
relevant
now
with
work
from
home?
You
know
remote
work
and
remote
offices,
it's
hard
to
make
the
assumption.
You
know
you're
coming
in
from
the
internet.
D
How
do
you
identify
this
user
now
and
we've
done
this
for
some
time
now
in
the
user
space
you
authenticate
yourself
against
an
identity
service,
the
identity
service
unbeknownst
to
you
is
giving
you
some
identity
context
to
your
browser
and
then
you're
presenting
that
to
the
application.
The
applicant
application
makes
a
determination
who
is
rf
and
sure.
Do
you
have
access
to
this
application
right?
We
solve
that
problem
in
the
user
world.
D
C
Yeah
it's
funny.
I
read
an
article
once
recently
about
what
xero
trust
is
not,
and
the
first
one
was.
I
have
a
vpn
and
you're
right,
because
anybody
could
well
not
anybody,
but
you
could
sign
up
to
a
vpn
but
get
access
to
all
these
other
resources
and
assets
that
maybe
you
shouldn't
have
access
to.
So
have
your?
Have
you
seen
an
increase
in
your
customers
asking
about
xero
trust
because
of
the
actual
executive
order
that
was
released
a
couple
months
back?
I
think
it
was
mentioned
in
there
like
11
times.
D
D
We
we
certainly
saw
the
increase
given
prior
to
that,
but
I
think
that's
just
fueled
it
even
more.
I
would
say
clearly,
obviously,
when
you
have
an
omb
mandate.
I
remember
you
know,
maybe
I'm
dating
myself
a
little
bit
when
we
had
the
ipv6
omb
mandate.
Everybody
was
like.
Oh,
we
gotta
have
ipv6
support
right.
I
used
to
work
for
juniper
networks
back
then
we
were
like
oh
yeah.
All
of
our
technology
needs
to
have
ipv6
right,
but
yeah
you're
right
I
mean
that's.
Certainly
that's
something!
D
D
Yeah
I
mean
look
on
the
on
the
I'll
start,
with
the
networking
side
focused
on
zero
trust,
network
security
and
we'll
delve
into
the
other
areas.
The
on
the
networking
side,
the
the
with
the
addition
of
the
micro
segmentation
capabilities,
we're
bringing
into
prismacloud
all
of
the
things
that
we
built
around.
D
You
know:
workload,
identity,
authentication,
authorization,
that's
really
the
crux
of
the
technology
that
we've
added
to
prismacloud
for
zero
trust,
network
security,
right
and-
and
so
that's
certainly
an
area
of
investment.
For
us
there
are
other
areas
where
we
think
about
zero
trust
and
those
have
to
do
with
things
like
permissions,
lease
privilege
permissions.
D
So
when
I
talked
about
identity
access
management,
the
iam
capabilities
that
we
have
that's
another
area
of
investment
for
us
making
sure
that,
because
you
want
to
give
least
privilege,
you
want
to
figure
out
if
this
asset
should
actually
have
this
privilege
to
access
something
else.
So
that's
another
area
of
zur
trust
that
we're
investing
in.
C
D
Yeah
alex
does
a
pretty
good
job,
but
I'll
just
set
it
up
for
him
a
little
bit.
You
know
what
we're
going
to
show.
You
is
essentially
our
the
integration
of
our
technology,
the
the
the
apparatus
technology
into
prismacloud
and
what
is
now
the
microsegmentation
module
and
all
of
the
capabilities
around
that
so
essentially
the
general
availability
of
this
product.
Just
to
show
you
a
quick
demonstration
of
what
we're
capable
of
alex.
Take
it
away.
E
E
So
just
to
get
started.
What
we
have
here
is
the
solution
deployed
in
a
kubernetes
cluster.
It
could
be
like
kubernetes
could
be
a
virtual
machine
running
like
red
hatch
or
a
windows
right
os
or
any
sorts
of
different
linux
flavors.
So
what
we
have
here
is
just
the
enforcer
which
you
can
think
about
the
enforcer
as
an
agent
that
is
deployed
in
your
openshift
cluster
or
your
kubernetes
cluster,
just
running
like
a
demo
sat,
so
I
have
six
enforcers
here
just
because
of
my
cluster.
E
If
you
don't
have
this,
if
you
are
a
prismacloud
customer
today,
when
you
don't
see
this
tab,
it's
just
because
this
model
is
pre-ga
obga
in
a
couple
weeks
and
then
you'll
be
available
across
all
customers
and
all
tenants,
but
you
can
actually
test
that
technology
today.
If
that's
on
your
interest,
then
going
back
to
the
environment,
but
here
what
you
can
see
are
all
the
pods
I
have
inside
my
namespace.
I
have
a
specific
namespace.
You
could
have
visibility
across
all
of
your
environments
and
you
can
deep
dive
into
specific
applications
here.
E
I
just
have
one
application
which
is
running
like
in
my
cluster,
and
you
can
see
all
the
traffic
relationship
between
the
parts.
You
can
see
that
our
pods
that
are
connecting
to
dns
servers,
pods
that
are
connecting
to
specific
google
service
pods
that
are
connecting
to
the
metadata
service
and
pods
that
are
receiving
traffic
from
the
load
balancer.
For
example,
I
can
actually
click
on
the
pod
itself
and
have
visibility
on
all
the
metadata
that
we
extract
off.
This
serves
as
irfa
mentioned
right.
E
We
are
identity
based,
which
means
we
are
collecting
metadata
out
of
every
single
resource.
We
are
protecting,
generated,
assigned
and
cryptographic
token
that
is
uniquely
assigned
to
that
instance.
So,
when
this
distance
is
now
trying
to
communicate
to
something
else,
we
are
doing
authentication
right.
Is
this
frontier
anthropology
exactly
who
it
claims
to
be,
and
then
we're
leveraging
this
right
signed
tokens
to
do
that
and
then,
if
it's
authenticated,
it's
also
authorized.
E
So
you
can
see
that
we
are
collecting
operational
system
data
cloud
provider,
metadata
application,
metadata
itself
and
custom
tags
that
you,
as
a
user,
can
be
assigned
to
your
pods
or
vms
right
after
I
do
that
I
can
actually
inspect
the
phone
and
see
what
exactly
is
happening
here
right.
So
I
can
see
all
the
flows
and
all
the
traffic
and
the
policies
that
are
allowing
these
traffic
to
happen.
So
now
I
have
a
policy
that
says:
oh,
I
can
access
the
frontier
and
components
and
what
this
policy
actually
says
right.
E
It
says
that
traffic
coming
from
the
load
balancers
in
tcp,
80
and
tcp,
443
or
different
ports
right,
are
allowed
to
reach
out
to
my
application.
Important
to
mention
there
is
zero
network
constructs
in
this
policy,
we're
just
leveraging
metadata
and
you
as
a
security
engineer
as
an
application
owner.
You
can
think
about
this.
E
I
am
now
defining
what
is
allowed
to
be
in
my
application
or
in
my
subnet
or
my
entire
cloud
environment,
based
on
compliance
checks
based
on
security,
right
policies
that
I
have
or
business
controls
like,
for
example,
front
change,
can
access
back
edge,
so
the
application
owners
can
now
create
their
policy
just
using
the
metadata
they
already
used
today,
like
all
those
labels,
so
from
jng
equals,
allow
it
to
access
back-end.
I
don't
need
to
leverage
networking
ip
address
things
like
that
which
may
be
alien
to
a
developer
right,
they're,
not
versatile
network
security.
E
So
now
security
teams
can
define
the
guard
derails.
For
example,
right
no
application
can
talk
to
each
other
between
namespace,
which
is
exactly
what
happened
in
here.
I
have
this
namespace,
which
is
has
this
right
name
of
rogue,
which
is
trying
to
reach
out
to
services
in
my
application,
so
he's
trying
to
escape
his
own
namespace
to
access
different
namespace
and
now
he's
been
blocked,
because
I
have
a
policy
created
by
the
security
team
that
defines
no
traffic
between
namespace
can
actually
ever
happen.
If
they
need
to
happen,
they
need
to.
E
They
need
to
have
a
business
reason
and
then
we're
going
to
have
a
policy
that
explicitly
allows
that,
but
by
default
different
than
what
kubernetes
does
and
I'm
not
allowing
namespace
to
talk
between
them.
So
then,
I
have
all
this
visibility
in
my
pods
and
understand
the
traffic
relationship
and
see
what's
going
on
there.
E
Another
interesting
aspect
of
it.
It's
rather
than
just
going
to
the
y
and
creating
these
policies
manually.
Here,
how
can
I
leverage
policy
as
coach
to
the
to
give
power
and
moving
from
a
centralized
board,
like
airflow,
mentioned,
to
a
decentralized
work
where
devops
can
write
their
policy
as
code
and
have
them
deployed
in
the
pipeline
directly?
E
So
what
I
have
here
is
just
two
pipelines,
one
that
creates
an
application
in
my
cluster
right
and
I'm
using
like
cloud
build
to
do
that.
But
it's
really
just
a
tool
right,
it
could
be.
Anything
else
could
be
jenkins,
could
be
quake,
would
be
code
pipeline,
azure,
devops,
etc,
gitlab,
etc.
Then
I
will
deploy
this
demo
app
and,
alongside
the
application
being
deployed
in
the
cluster,
I'm
also
adding
the
policies
as
code
right.
It's
just
a
yemo
definition
that
dictates
exactly
what
policy
should
be
allowed
in
cluster.
E
And
you'll
be
able
to
see
that
once
the
application
is
deployed
in
kubernetes.
I
also
also
automatically
have
the
micro
segmentation
policies
created
on
it
and
you'll
be
able
to
see
here
in
my
cluster
a
new
namespace
called
the
demo
app
we're
going
to
be
able
to
see
this
application.
Just
to
give
you
a
different
view.
E
While
we
wait
for
the
pipeline
to
run,
I
can
actually
have
visibility,
not
just
across
just
one
application,
as
I
initially
mentioned
now,
I
can
have
the
visibility
of
my
entire
cluster
and
all
the
namespaces
on
it,
so
you
can
have
visibility
that
going
from
the
top
I'm
actually
seeing
my
entire
data
center,
my
entire
cloud
account
or
you
can
deep
dive
and
just
have
visibility
across
a
specific
application
right.
So
you
can
see
all
those
applications
existing
here
right
then
we
can
actually
see
that
my
demo
app
is
already
created.
E
E
Here
allow
internal
traffic.
So
let's
just
look
at
this
definition
right
as
you
can
see
just
a
yaml
file
that
says,
allow
internal
traffic
between
all
the
pods
inside
the
namespace
right,
very
simple
one.
So
I'm
just
saying
that
allow
everything
that
happens
inside
my
namespace
in
any
ports,
I
can
actually
write
granular
policies,
as
I
want
right.
Just
leveraging
metadata
like
front
change,
equals
back
end
right
frontiers,
you
can
access
back
engine
on
specific
reports
here.
E
E
E
C
C
D
Let
me
start
with
that.
If
you
go
about
alex,
if
you
just
go
to
the
one
of
the
workloads,
if
you
click
on
one
of
them
and
then
if
you
just
go
to
the
root
set
text,
yeah
so
dave
the
way
it's
working
and
I
was
gonna-
you
know
I
didn't
know
at
one
point
to
dive
into
this
deep,
deep
detail,
but
I
think
part
of
the
demo
is
a
good
time
so
what's
happening
here.
Is
this
this
specific
workload?
Has
these
tags
associated
to
it
right
these
key
value
pairs
right?
D
D
What
we're
doing
is
we're
taking
this
identity
information,
these
tags,
these
key
value
pairs
and
we
only
take
the
relevant
ones,
the
ones
that
are
most
relevant
to
you
know
to
enforce
the
specific
rule
and
we're
actually
exchanging
it
as
part
of
the
three
three-way
handshake
so
with
tcp
there's,
actually
a
way
for
you
to
insert
payload.
It's
called
tcp
fast,
open
options
and
you
can
insert
some
payload
information
that
actually
has
these
tags
and
the
token
that
you
highlighted
what
it
is
is
actually
a
json
web
token.
D
So
we've
taken
concepts
in
the
web
world.
Remember
if
I
I
talked
about
the
fact
that
users
authenticating
themselves
against
an
identity
service
and
then
logging
into
an
application
well
turns
out.
We
use
json
web
tokens
for
http
we've
just
taken
that
concept
brought
it
down
to
tcp
and
we're
using
jet.
We
use
the
json
web
token
that
actually
has
these
key
value
pairs
as
information.
Within
that
token
and
it's
signed
so
it's
you
know:
crypto
cryptographically,
verifiable,
that's
how
you
authenticate
and
it's
that
exchange
happens
as
part
of
the
three-way
handshake.
D
C
Okay,
cool
another
question
is
around
the
policies.
What
do
you?
What
are
you
saying
I
guess
in
terms
of
customers
or
recommendations
who
who
first
creates
those,
do
do
security
professionals
work
with
developers
to
create
those
or
there's,
maybe
a
company
sort
of
bag
of
templates
or
whatever,
and
then
developers
picked
from
them?
What
have
you
seen.
D
So
my
our
assessment
from
most
customers
today
that
look
at
technology
like
this
is
this:
centralized
security
teams
want
to
have
the
guard
rails
that
they
want
to
put
in
place,
which
is
perhaps
internet
access,
is
a
guardrail
rule
like
I
will
only
allow
you
know
you
have
to
it's
all
these
centralized
security
teams
will
allow
access
to
you
know
things
on
the
internet
right.
That
could
be
one
guardrail
that
they
put
in
place.
Other
guardrails,
like
as
alex
mentioned
in
this
example,
are
things
like
you
know,
namespace
isolation.
D
You
know
no,
no
communication
between
namespaces,
only
communication
allowed
within
that
namespace
and
you
can
define
those
rules.
So
the
centralized
security
teams
want
to
define
the
guard
rails
and
then
they
want
to
be
able
to
offload
some
of
those
rules
to
the
development
teams.
That's
where
we
see
most
customers.
You
know
love
this
approach
of
you
know
using
name
spaces
and
hierarchical
rules
to
to
enable
developers.
D
We
certainly
see
some
organizations
where
everything
is
being
defined
by
centralized
security,
but
I
think,
as
they
make
the
transition
towards
more,
you
know:
devops
and
dev
tech,
ops,
types
of
deployments
and
and
operationalization
mechanisms
they
they
tend
to
favor.
This
type
of
approach,
yeah
yeah.
D
E
Yeah,
I
think,
there's
right,
as
you
mentioned,
if
there
is
all
kinds
of
deployments
and
all
kinds
of
environments,
so
some
customers
they
really
like
to
work
with
the
template
mode,
as
you
mentioned
avalos,
so
they
have
their
set
of
templates,
that
the
security
team
writes
and
then
the
dabs
will
use
it
according
to
their
needs.
That
are
people
who
deploys
the
application
in
the
pipeline.
They
have
right.
E
One
of
the
tasks
is
to
profile
the
micro
cementation
policies
and
then
define
right,
writes
their
policies
based
on
the
requirements
they
find
out
during
the
uag
test,
and
then
they
write
this
template
and
it's
deployed
when
it
goes
into
production.
So
they
have
a
testing
phase
where
they
create
all
the
policies,
and
then
they
have
the
deployment
phase
where
it
goes
into
production,
and
there
are
environments
where
people
really
just
use,
centralized
controls
right,
for
example,
namespace
segmentation
or.
E
And
then
the
devs
will
leave
with
those
restrictions,
so
I
think
the
important
piece
is.
We
support
all
those
different
types
of
right
deployments
and
different
types
of
methodologies
to
work
with.
There
are
things
we
are
working
on
in
the
products
to
make
this
even
simpler
right
and
two
specific
policies
which
one
it's
called.
What
we
define
as
policy
suggestions
right,
so
assuming
a
scenario
where
the
user
is
just
getting
started
with
the
technology.
It's
starting
his
micro
segmentation
journey
there's
a
lot
of
things
he
needs
to
do
and
he
needs
to
understand.
E
So
how
can
I
get
better
uses
of
the
platform
without
being
an
expert
myself
right?
How
can
I
start
taking
leveraging
the
platform
in
day
one?
So,
policy
suggestions
are
a
feature
that
we
are
going
to
introduce
pretty
soon
in
the
platform
that
provides
you
some
recommendations
on
things
you
need
to
enable
right.
If
you
want
to
do
like
a
namespace
segmentation,
simply
click
here,
and
then
we
will
create
those
policies
automatically
for
you.
E
They
wanted
to
allow
traffic
to
specific
infrastructure
services
right,
like
dns
ntp,
windows,
updates,
ready
hat
updates,
so
just
click
on
this
policy
and
then
we'll
create
that
for
you
and
that
policy
suggestions
is
going
to
be
like
a
leveraged
predefined
candidate
policies
that
you
can
just
click
and
having
them
deployed
in
your
environment.
Without
you
knowing
anything
about
the
platform
itself,
the
second
one
is
what
we
call
a
profile
it
a
profiling.
It's
as
the
name
suggests.
E
How
do
I
profile
all
the
traffic
items
in
here
in
my
application
and
automatically
generate
templates
that
I
can
use
in
my
pipeline
right
without
me
having
to
write
a
single
policy,
so
we
will
be
observing
the
flows
right
in
all
those
flows.
We
can
see
here
in
the
app
dependency
map
they
are
being
observed
by
the
platform
and
based
on
these
characteristics,
a
set
of
granular
road
sites,
which
will
be
the
least
privilege
for
this,
for
your
application
will
be
generated
as
a
template.
E
Then
you
can
take
this
template,
deploy
using
your
pipeline
and
deploy
your
application
completely
like
segmented
from
the
get
out.
I
can
also
be
as
a
ui
user.
Oh
those
are
the
recommendations,
that's
the
granular
set
of
policies.
I
need
in
my
environment,
just
push
them
and
deploy
them
so
app.
Profiling
is
really
about
learning
about
your
application
requirements
and
dependency
and
having
the
policy
suggested
that
you
should
be
applied
there,
and
then
you
can
export
those
results
and
using
your
pipeline.
C
C
To
ask
a
related
question
to
that:
around
best
practices
or
recommendations
for
namespaces,
I'm
assuming
you,
you
don't
recommend
having
one
namespace
for
production,
which
I've
heard
recently
a
company
did
one
time,
but
what
what's
sort
of
the
happy
medium
in
terms
of
how
many
spaces
do
you
create
per
application,
or
you
know,
per
company
or
per
division?
What
what
are
your
thoughts
around?
That.
E
Sure,
okay,
so
namespaces
in
in
in
the
kubernetes
definition
right.
I
always
recommend
having
your
applications
separated
by
namespace,
so
I'm
going
to
have
like,
for
example,
here
I
have
the
buchi
app
right,
so
it
doesn't
dedicate
the
namespace
and
everything
that
belongs
to
the
boutique
act
exists
here
in
this
namespace.
I'm
gonna
have
other
applications
like
the
demo,
app
or
just
deployed
or
guest
book
or
any
other
applications
payments.
They
need
to
be
in
their
own
environment
right
and
they
need
to
be
in
their
own
namespace.
E
So
then,
if
I
have
a
requirement
to
applications,
they
don't
should
be
talking
to
each
other.
Then
they
are
completely
segmented
by
default.
I
just
enable
the
policy-
and
I
get
this
segmentation
right
right
there.
I
can
have
the
kubernetes
clusters
that
serves
multiple
purpose.
They
can
serve
production
apps
and
maybe
when
we
find
these
quite
often
they
also
serve
testing
apps
right,
but
they
are
in
the
same
cluster.
Then
leveraging
metadata,
I
can
say
any
namespace
where
the
pods
have
this
label
production.
E
E
So
I
think
for
in
terms
of
visualization
and
best
practices,
always
separate
your
applications
by
namespace,
if
you
can
have
those
applications
like
those
tiers
project
and
development
and
staging
separated
in
different
clusters,
even
better,
if
you
can
afford
this,
then
having
them
is
too
separated
on
by
namespace
and
making
sure
that
you're
leveraging
the
proper
metadata
in
this
case,
proj
dev
staging
things
like
that,
so
it
becomes
easier
for
you
as
a
security
engineer,
to
write
a
policy
that
says
production.
Namespace
can
never
talk
to
development
or
station
next
space.
D
I'll
give
you
one
example:
on
top
of
what
alex
said
I'll,
just
tell
you
our
entire
backend
infrastructure.
For
this
that
you
see
here
is
actually
based
on
kubernetes
today
and
the
way
we
do
it
is
actually
we
we
have
separate.
We
have
a
dev
in
a
product
cluster
right
and
one
of
the
benefits
to
this,
for
us
has
been.
You
know
when
we
do
a
product
cluster.
When
you
go
to
the
auditor,
we
went
through
a
sock,
two
type
of
audit.
D
It
makes
it
much
simpler
actually
to
prove
to
the
auditor
that
you
know
who's
touching
the
product
cluster
versus
who's,
touching
the
dev
cluster,
those
sorts
of
things,
I
think,
definitely
as
alex
mentioned,
if
you
have
the
ability
to
actually
launch
different
clusters
for
dev
and
prod,
I
would
definitely,
I
think,
that's
from
my
you
know,
experience
managing
having
looked
at
this
as
one
of
the
recommendations.
I'd
make
the
other
thing
around
namespaces.
D
Surprisingly,
dave
I've
noticed
a
lot
of
organizations
today
they
do
app
level
segmentation
for
namespaces,
so
essentially
app
owners
have
their
own
namespace
and
they
just
segment
it
that
way,
and
it's
actually
worked
out
even
today
at
panit,
which
is
our
I.t
department
within
paulo
to
networks.
That's
how
we
do
it.
We
actually
segment
using
namespaces
to
segment
different
app
owners
and
I've
seen
other
customers.
Do
it
that
way.
C
Yeah,
it
might
have
sounded
in
my
mind
it
was
a
basic
question,
but
asking
that
question
to
you
all,
I
think,
has
some
interesting
implications
because,
as
a
development,
the
former
developer,
when
I
was
thinking
about
well,
how
should
I?
How
should
I
create
my
name
spaces?
I
rarely
thought
about
security.
C
C
D
No,
it's
a
very
important
point.
Yeah.
You
can
obviously
you
you
can
dig
yourself
a
hole
by
trying
to
go
really
granular,
but
at
the
same
time
you
can
try
to
figure
like
really.
What
you
need
to
assess
is
what
is
the
risk
that
you're
trying
to
mitigate
right
and
my
my
sort
of
discovery
and
having
talked
in
a
number
of
customers
in
this
space
and
actually
what
we
do
even
to
protect
our
own
backend
infrastructure?
D
D
It's
the
boutique
app,
not
the
software
yeah,
so
you've
got
you
know,
front
end,
you
know
payment
services.
All
of
these
are
microservices,
but
the
way
you
know
you
can
think
about
it
is
you
can
put
all
these
within
a
single
name
space
and
you
can
isolate
this
specific
application
like
comp,
like
you
know
anything
that
wants
to
talk
to
this
specific
application,
you
can
explicitly
define
rules,
but
a
simple
rule
can
be
anything
within
this.
Namespace
can
talk
to
each
other.
Anything
outside
this
name.
Space.
D
I'd
like
to
define
explicit
rules
like
okay,
if
front
end
or
obviously
front
then
needs
to
talk
to
the
internet.
Then
you're
definitely
explicit
to
find
those
rules,
but
if
some
other
services
like,
for
instance,
you
have
a
dependency
on
a
shared
service
that
you
want
to
that.
This
specific
application
has
a
dependency
on.
Then
you
want
to
explicitly
define
those
rules.
That's
the
way
I've
seen
most
customers
think
about
it.
They,
you
know,
there's
some
terms
in
the
industry
called
ring
fencing.
D
If
you
ring
fence
around
a
specific
application,
you
allow
anything
inside
that
application.
The
components
that
talk
to
each
other
and
then
you
explicitly
allow
you
know
communications
outside
and
I've
seen
that
as
a
as
a
way
to
kind
of
solve
this
problem,
because
you
certainly
don't
want
to
you
know,
get
get
too
granular,
because
at
that
point
you
know
things.
You
know
it
might
just
add
operational
complexity
with
less
benefit.
C
C
E
C
Yeah,
I
guess
my
my
last
question
is
sort
of
future
thinking
and
I'm
not
asking
for
road
map.
But
where
do
you
all
think
micro
segmentation,
zero
trust,
is
going
in
the
future?
What
are
the
big
things
like
in
your
in
your
head
and
your
brain
in
terms
of
what
what
we
have
to
solve
for
next
is?
Is
it
going
to
be
something
new
other
than
kubernetes
that
we
have
to
worry
about?
What
are
your
thoughts.
D
Yeah,
it's
a
good
question
and
we're
always
thinking
about
sort
of
you
know
how
the
how
technology
is
evolving,
how
you
know
kubernetes
is
evolving
over
time
and
on
how
you
know
in
this
instance,
even
how
microservices
are
being
deployed.
I
think
you
know
one
of
the
things
that
I
definitely
see
a
shift
that
will
happen
is
we're
thinking
about
layer,
3,
layer,
4.
You
know
network
segmentation
using
tcp.
D
I
think,
as
you
move
to
a
world
of
microservices,
you
know
in
kubernetes
you
have
the
concept
of
services,
so
things
get
front-ended
through
a
load
balancer,
and
you
know
you
start
to
think
about
tls
as
the
next
tier
and
then
even
above
that,
like
you,
know,
start
to
think
about
http
level.
You
know:
authentication
authorization,
api
level,
granularity
in
terms
of
defining
what
should
access
what
others,
I
think,
that's
where
the
future
is
going
to
go
for
a
technology
like
us.
In
fact,
that's
where
we're
making
investments
I'll
give
you
a
simple
example.
D
The
next
thing
we're
looking
at
doing
and
and
it'll
come
out
shortly
is
moving
this
to
a
services
layer,
essentially
with
tc
with
tls
right.
So
considering,
instead
of
looking
at
it
from
a
tcp
perspective,
essentially
using
mutual
tls
to
solve
this
authentication
problem,
but
then
have
authorization
on
top
of
it
as
well.
There
are
many.
D
Actually
there
are
a
few
vendors
out
there
that
solve
being
able
to
enable
mutual
tls
for
you,
but
we're
looking
at
okay,
not
just
looking
at
mutual
tls
for
authentication
mechanisms,
but
even
for
authorization
right.
So
that's
where
I
would
see
the
next
step
and
and
and
and
further
to
that
start
to
look
at.
You
know
api
level
granularity
as
well.
You
know
not
just
being
able
to
say
this.
Pod
can
talk
to
this
pod.
C
D
I
think,
but
they're
they're
trade-offs
here.
One
thing
that
I
will
mention
you
know,
and
this
comes
again
from
talking
to
a
lot
of
customers
like
as
you
go
further
up
the
stack
as
you
start
to
think
about
tls
and
http.
You
know
you
start
to
end
up
being
a
proxy,
and
so
when
you're
a
proxy,
you
have
trade-offs.
You
have
to
now
you're
going
to
be
in
the
data
path
right.
D
D
C
C
A
C
You
know
brought
on
a
partner.
Sometimes
we
have
red
hatters
to
talk
about
the
category
of
the
month.
Our
other
shows
focused
primarily
on
partners
as
well.
Look
for
our
podcasts,
just
search
red
hat
podcast
and
you'll
find
the
streaming
service
there.
If
you
want
to
learn
more
on
and
by
the
way,
ref
and
alex,
I
just
put
the
palo
alto
prisma.
It
had
openshift
url
here.
C
I
think
that's
it
with
that.
I
want
to
thank
ari
and
alex
from
palo
alto
networks
and
this
great
demo
and
thought
leadership
around
micro,
cementation,
network
control,
xero
trust,
I'm
sure
we're
going
to
have
them
on
again
in
the
future,
because
they
definitely
hit
a
couple
of
those
other
categories
that
you
see
there
like
runtime
monitoring.