►
From YouTube: Webinar: Zero Trust Security for Cloud Native Apps
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
Going/gone cloud native? Then, you get tremendous scalability, resilience, and agility, yet how do you secure your microservices from data breaches, attack probes, or workload tampering. In this talk, learn about zero trust security best practices.
- How do you identify a microservice and ensure only legitimate communications are established?
- How do you securely scale communications among microservices?
- How do you use topology and policy visibility of your microservices to ensure security and compliance objectives?
- How do you prevent data exfiltration, attack probes, or workload tampering across your microservice?
A
Okay,
I
think
we
can
get
started.
Welcome
everyone,
today's
CN
CF
webinar.
The
topic
is
zero
trust
security
for
a
cloud
native
apps,
I'm,
Sanjeev,
Rampal,
I'm,
a
principal
engineer
in
the
container
platform
engineering
team
at
Cisco.
Thanks
to
all
of
you
who
are
joining
us.
Today's
topic
is
at
the
intersection
of
two
very,
very
important
areas:
security
and
cloud
native
technologies.
So
this
should
be
super
interested
super,
interesting
and
I'm.
A
Really
looking
forward
to
this
presentation,
our
presenters
today
are
or
Hein
Helmand,
who
is
the
co-founder
and
CTO
doctrine
and
give
Guinea
Pat's
who's
the
head
of
security
at
octarine,
a
couple
of
housekeeping
items
during
the
webinar.
You
will
not
be
able
to
talk
as
an
attendee,
but
there
is
a
QA
box,
so
feel
free
to
drop
your
questions
in
there
and
we
will
get
to
as
many
as
we
can.
A
C
C
So
when
we
were
talking
about
cloud
native
applications,
we're
talking
about
not
just
a
shift
or
a
fundamental
shift
in
the
way
applications
are
architected,
broken
down
into
micro
services,
but
also
in
both
compute
and
network
are
virtualized,
and
that
shift
and
that
that
change
has
to
translate
to
the
tools
that
we
use
to
secure
those
environments
so
that
this
talk
I'm
going
to
go
over.
What
drives
this
shift
and
what
are
the
necessary
requirements
of
a
new
security
framework
for
this
new
world.
C
C
This
traffic
targets,
thousands
of
internal
IP,
is
each
one
of
those.
Ap
is
maybe
a
target
of
an
attack
looking
to
access
data
or
perform
lateral
movement
to
monitor
this
traffic
and
secure
those
api's.
You
have
to
have
a
solution
that
is
as
scalable
as
those
cloud
native
workloads,
so
we'll
talk
more
later
about
what
it
takes
for
a
solution
to
be
scalable.
C
So
if
cloud
native
means
high-volume,
it
also
means
high
velocity
businesses.
They
adopt
the
cloud
native
approach
because
they
want
to
be
agile,
so
cloud
native
applications
are
usually
coupled
with
agile
deployment
model.
What
that
means
is
that
new
services
and
new
versions
of
those
services
are
deployed
frequently
in
some
cases
several
times
a
day
and
they're
deployed
in
a
centralized
way.
So
each
team-
and
in
some
case
each
developer,
is
responsible
for
the
point
parts
of
an
application
keeping
track
of
what's
deployed
and
how
it
behaves.
C
But
now
we're
moving
to
a
world
where
we
have
where,
instead
of
having
few
applications,
which
are
using
distinct
protocol,
pause
and
have
static,
well-known
Network
addresses,
we
have
a
world
of
many
scale-out
services
that
communicate
using
a
small
set
of
protocols
and
mostly
HTTP
HTTP.
Some
message
broker
protocols
and
where
network
identity
is
no
longer
couple.
Coupled
with
the
particular
worker.
C
So
yeah
our
services
now
our
stateless,
they
can
go
down
and
go
up
at
any
given
time.
The
orchestrator
has
freedom
to
spin
up
containers
and
allocate
IP
addresses
to
those
containers.
So
the
connection
between
an
IP
identity,
II
and
a
workload
is,
is
gone
so
just
knowing
the
service
server
or
something
an
entity
within
a
certain
IP
contacted
another
IP
on
port
8080
using
HTTP.
It
doesn't
matter,
it
doesn't
say
much
about
who
is
the
initiator
and
what
it.
What
is
it
trying
to
do
even
worse?
C
When
we're
talking
about
HTTPS,
we
don't
have
any
visibility
as
to
what
what
are
the
payloads?
What
are
the
endpoints
that
are
being
accessed,
we're
really
very
little
disability
as
to
what
what's
actually
going
on
and
now
in
this
environment,
we
also
see
a
lot
of
massive
use
of
load:
balancers
proxies,
reverse
proxies
API
gateways,
especially
in
public
clouds
and
all
those
intermediaries.
They
break
the
relationship
between
the
originating
IP
and
the
actual
IP
that
we
see
on
the
network.
I'm.
A
C
C
So
identity
is
obviously
a
fundamental
component
of
such
a
solution.
We
need
to
know
for
certain
who
are
the
actors
in
our
network
and
since
network
identity
won't
do
we
should
rely
on
identity
that
is
attached
to
the
workload
and
that
identity
is
the
one
being
transmitted
and
verified
across
the
network.
Using
mechanisms
like
a
mutual
to
TLS
in
therefore
and
sign
JWT
is
in
layer
7.
C
There
are
several
challenges
around
applications
identity.
The
first
one
is:
how
do
we
determine
the
identity
of
an
application,
also
called
attestation?
So
one
option
could
be
based
on
the
binary
or
the
image
we
can
hash
it
and
attach
certain
hash
to
an
identity
that
creates
some
problems
around
versioning.
So
when
we
create
a
new
version
of
our
binary
or
of
our
container,
image
will
have
a
different
hash.
So
we
still
have
to
know
that
it's
the
same
workload,
but
we
do
want
to
know
that
maybe
it's
a
different
version
so
behavior
might
be
different.
C
C
Of
course,
DNS
address
could
be
another
way
to
identify
the
workload
so
in
East
EO
we
rely
on
the
service
and
the
service
kind
of
create
is
related
to
the
DNS
name
and
the
port
that
this
workload
expose,
rather
than
specifically
to
a
deployment
and
and
a
good
solution,
should
probably
have
a
combination
of
all
those
approaches.
So
we
do
want
to
look
at
the
binaries.
C
We
do
want
to
have
integration
with
the
orchestrator,
and
we
do
want
to
validate
that.
The
DNS
address
that
the
clients
will
be
addressing
is
actually
represents.
The
right
work
second
problem
is
is
about
delivering
credentials
to
the
workload.
That's
the
identity,
bootstrapping
problem,
so
we
have
workouts
that
are
current,
constantly
being
spun
up,
and
obviously
we
don't
want
any
credentials
in
the
code
itself
or
the
container
image
and
an
even
secret
management.
C
So
the
native
secret
management
capabilities
of
let's
say
kubernetes
have
several
flaws
and
drawbacks
in
terms
of
security
in
terms
of
the
granularity
of
access
to
those
secrets,
what
we
really
want
to
do
is
to
have
a
minimal
exposure
to
unauthorized
access
or
spoofing
or
men
in
the
middle
attack.
So
we
want
the
credentials
to
be
delivered
at
the
very
last
moment
before
the
workload
actually
needs
to
use.
C
The
the
third
problem
is,
is
how
do
we
minimize
the
damage
of
credential
set
if
a
container
is
breached
compromised
if
our
secret
management
system
has
been
compromised?
How
assuming
we
identified
it?
How
do
we
minimize
the
damage
there
and
that
could
be
solved
by
a
frequent
rotation
of
credentials
and
a
runtime
binary
correlation
of
who
is
actually
using
those
credentials,
as
well
as
anomaly,
detection.
C
All
right,
so
micro-services
are
not
developed.
The
same
way
that
traditional
applications
were
we're
moving
from
a
world
where
we
use
a
uniform
development
platform
like
Java
spring,
to
develop
all
our
applications
to
a
world
where
we're
using
the
best
tool
for
each
task,
which
means
that
a
single
application
may
have
components
written
in
C++,
some
written
in
go
some
written
in
nodejs
and
and
I
always
see
one
a
security
solution
that
will
cover
all
your
workloads
in
a
uniform
way,
regardless
of
how
they
were
created
and
where
they
were
deployed.
C
C
Obviously,
you
want
your
solution
to
be
to
work
on
public
clouds
and
on
pram
and
and
in
between
those
clouds
and-
and
it
sounds
obvious,
but
it's
really
easier
said
than
done.
When
you're
using
a
public
cloud,
the
provider
they
integrate,
there,
I
am
and
logging
solutions
into
every
component
of
their
platform.
Your
compute,
your
networking,
your
data
services
and
it's
only
man
natural
to
manage
your
visibility
and
identity
and
access
control
with
those
those
native
tools,
but
a
good
multi
cloud
solution.
C
It
has
to
offer
both
hooks
to
integrate
those
native
I
am
and
logging
an
auditor
auditing
tools,
but
it
needs
to
extend
the
capabilities
where
their
capability
is
missing
and
it
has
to
offer
a
uniform
user
experience.
So
once
you
know,
if
you
want
to
migrate
an
application
from
your
on-prem
environment
to
the
public,
to
the
public
cloud
or
maybe
from
one
table
to
another,
your
experience
in
terms
of
security,
should-should
status,
things.
C
So
the
last,
the
last
part
is
about
trust,
so
your
your
traffic
is
going
to
be
traveling
across
networks
and
they
will
have
varying
trust
levels,
so
it
could
be
within
a
VP
C
among
VP
sees
within
among
zones
among
clouds.
So
it's
best
to
adopt
this.
Your
trust
approach,
where
all
your
communication
is
encrypted
and
authenticated
at
the
Empire.
That
means
that
the
initiator
identifies
itself
and
the
server
authenticates
that
identity
and,
of
course,
everything
in
the
middle
has
to
be
encrypted.
C
Some
some
people
think
that
encryption
is
costly,
but
today
with
modern
CPUs,
that
overhead
is
actually
very
small
and
it's
actually
smaller
than
the
overhead
of
parsing
the
payload.
In
many
cases,
an
encryption
is
not
just
critical
in
protecting
the
actual
payload
from
youth
dropping.
It's
also
the
only
way
to
implement
stronger
authentication
that
that's
not
vulnerable
to
men
in
the
middle
attack.
C
So
we
talked
about
the
problem.
We
talked
about
the
design
principles
now,
let's
look
a
little
bit
at
possible
implementation.
So
if
we're
going
back
to
the
principle
of
application,
independence
as
the
sidecar
model
is,
is
the
way
to
add
some
capabilities
in
a
uniform
way
for
different
kinds
of
applications.
So
the
sidecar
is
a
separate
process.
It's
running
alongside
the
service
and
an
extending
its
capabilities
in
in
the
CNCs
world,
I
guess
the
most
famous
sidecars
is
employed
as
it
handles
both
some
security
aspects
and
many
routing
and
failover
tasks.
C
C
C
Now
some
tasks
are
very
complex
in
this
dynamic
environments,
like
key
management,
are
greatly
simplified.
There
are
a
lot
easier
when
you
have
this
standard
component
running
at
every
endpoint.
So
now
you're,
your
cycler
is
the
one
handling
communication
with
your
CA
and
rotations
a
rotation
of
credentials
and
an
attestation.
C
So
what
happens
if
we
have
an
intruder
in
the
network?
So
if
it
doesn't
have
that
sidecar
that
has
gone
through
the
process
of
obtaining
identity,
it
will
not
be
able
to
authenticate
itself
and
obviously
any
attempts
of
accessing
other
services
will
be
denied
and
we'll
start
getting
alerts
that
possible
intrusion
is,
is
going
on
and
and
that's
really
the
essence
of
zero
trust,
because
it
doesn't
matter
how
close
the
intruder
got
to
our
workload.
It
could
be
in
our
V
PC
with
an
IP.
That's
in
our
subnet.
C
C
So,
even
if
we
haven't
authorized
workload
that
does
have
a
proxy
and
does
have
an
identity
and
that
workload
is
compromised.
If
we
have
an
effective
access
control
policy
in
place,
it
will
limit
limit
the
blast
radius
of
the
attack
to
just
a
very
small
subset
of
the
services
and
resources,
instead
of
exposing
all
the
resources
that
are
available
across
across
the
network.
C
In
addition
to
just
creating
a
strict
access
control
policy
and
enforcing
it
again,
binary
validation
can
and
should
be
used
to
make
sure
that
the
application
talking
to
the
proxy
is
the
right
application
pattern.
Based
detection
can
be
used
to
detect
API
scans,
sequel
injection
code
injection
and
an
anomaly
detection
tools
can
be
used
to
detect
the
change
in
the
use
pattern
like
the
payload
size
and
the
request
frequency.
C
So
so,
first,
it's
it's
using
whitelist.
So
it's
much
easier
to
characterize
a
workload,
but
by
what
it's
supposed
to
do,
what
is
the
intent
for
that
workload
rather
than
defining
and
verifying
what
is
it,
what
what
an
attack
would
look
like?
So
there
are
endless
kinds
of
attacks,
but
there
is
a
very
limited
set
of
actions
that
service
should
be
doing
so.
C
What
we
found
looking
at
actual
service
to
service
communication
cases,
is
that
the
the
a
back
approach,
the
attribute
based
access
control,
where
there
are
no
roles,
and
we
just
assign
allowed
actions
to
the
attributes
that
the
service
has,
we
find
it
a
lot
more
intuitive
and
it
usually
leads
to
a
simpler
and
more
flexible
set
of
rules.
I
invite
you
to
check
out
maple
it's
an
open-source
project
that
we
released.
It
includes
language
policy
definition,
language,
an
engine
to
interpret
that
language
and
a
nice
tio
authorization
adaptor.
D
A
D
Understand
how
we
can
mitigate
them,
using
some
of
the
some
of
the
concepts
and
design
principle
behind
talk,
so
I'll
share
my
screen,
one
second,
all
right
so
so
this
is
so.
This
is
a
basic
basic
cloud
native
architecture,
which
consists
of
the
things
guestbook
application,
which
is
the
hello
world
of
the
native,
the
hello
world,
app
for
call
native
applications,
and
we
have
also
a
passer
which
is
a
basic
application.
A
basic
REST
API
application
so
actually
actually
consists
of
four
four
services.
D
We
have
a
front-end
app
that,
yes,
all
the
incoming
traffic
from
the
world,
we
have
the
Redis
service,
which
is
the
database.
We
have
some
sensitive
service
and
we
have
pasture
which
exposes
REST
API,
so
the
certain
sensitive
service
actually
communicate
both
with
the
database
and
both
with
the
REST
API,
and
we
also
have.
D
One
second
yeah
just
think
that
my
screen,
okay,
yeah
I,
think
my
descriptions,
which
I
was
fine,
so
yeah,
sorry,
and
so
we
have
the
front-end
application
to
communicate
with
the
database
and
with
the
pastor
as
well
so
sure
my
terminal.
So
so
we'll
start
so
here
I
can
see
all
my
old
pose
of
this
deployment
and
so
we'll
start
detector
Omaha
from
a
breech
body.
D
So
in
that
case
we
will
just
bash
into
into
the
front
end
to
the
front
is
forward,
though,
in
a
real
case
scenario,
probably
the
detector
will
get
into
the
front
end,
who
gets
into
the
front
end
thought
through
some
remote
code,
remote
code,
execution,
vulnerability
and
probably
will
start
from
the
front
and
service
duty,
the
vulnerable
nature
of
front-end
application
through
a
SQL
injection
or
other
logic
model
or,
and
it
knows
no
dependencies
or
ran
any
other
any
other
remote
code
execution.
So
now,
let's
assume
we
are
inside
both
already
so
the
first.
D
So
the
first
thing,
usually
in
a
phone
native
Decker,
will
try
is
to
try
and
directly
talk
to
the
latest
API,
because
kubernetes
api
actually
administrate
the
whole.
That
is
faster
and
we
can
get
a
lot
of
information
from
there.
So
that's
curl,
let's
download,
cube
CTL
to
the
pod,
change
the
to
execute
permissions
and
now,
let's
run
it
and
try
to
see
which
other
services
are
in
that
deployment.
So
to
reach
other
services,
we
can
reconnaissance
and
get
more
information
and
maybe
move
to
more
sensitive
services.
D
So
let's
dig
up
CTL
and
yet
services,
so
it
doesn't
work.
We
are
forbidden,
looks
like
I've
come
out,
the
cluster
is
configured
correctly
and
it
uses
our
bug
arm,
which
is
the
best
practice.
So
we
are
not
lucky
in
that
case,
and
so
now
it
doesn't
mean
we
can't.
We
can't
access
the
kubernetes
api.
That
doesn't
mean
we
can't
communicate
with
other
services
or
or
find
them
might
find
those
services
by
other
means.
So
the
second
thing
that
we
can
try
is
to
look
at
the
environment
variable.
D
So
if
you
look
at
the
environments
variable,
we
can
see
some
IPS
of
probably
interesting
pods,
so
we
can
see
here
on
IBS
and
force
of
Redis
already
services.
So
let's
do
grab
Redis
and
you
can
see
here
on
IP
and
boards
of
the
Redis.
So,
let's,
let's
connect
to
it,
see
if
we
can
connect
to
that
and
get
some
some
interesting
data
from
there,
so
we
can
use
net
cut,
so
you
can
use
to
get
those
tools,
give
use
apt
if
it's
available
in
the
container,
but
we
can
actually
get
it
with
them.
D
W
get
or
or
Carol
so
I
just
already
installed
that
it's
using
app
to
save
some
time
for
the
demo,
so
that
saw
connect
via
get
okay.
So
we're
connected.
Let's
see
all
the
keys
readies
come
on,
kids,
Astrix.
Okay,
we
have
some
messages
left,
let's
see
what
messages
are
inside,
you
have
messages,
so
you
can
see
all
the
maze
messages
that
should
just
some
three
down
be
messages
that
I
beforehand
the
application
it
looks
like
we
can.
We
have
to
access
to
the
database
now
on.
D
We
can
read
and
write
to
the
database.
So
that's
one
thing
that
we
achieved.
So
let's,
let's
see
what
what
else
can
we
do?
Let's
see
how
we
can
discover
more
more
interesting
services,
saying
the
environment.
Variable
looks
like
we
don't
have
other
interesting
information,
but
we
can
do
natural
scan
that
we're
scanned
to
to
get
other.
Yet
other
information,
eyepiece
and
pores
of
other
services
around
us,
so
full
and
maps
can
we'll
take
a
lot
of
time.
So
we'll
just
scan
the
subnet
of
our
board
and
we'll
hope
to
find
some
something
interesting.
D
D
Shouldn't
take
too
long.
This
is
going
only
through
to
the
most
used
and
common
ports.
So
we
might
miss
some
some
open
chords,
but
it
should
find
the
most
interesting,
usually,
okay,
so
yeah
we
have
our
T
few
open
IPs.
We
won't
go
through
all
of
them,
but
let's
let's
go
through
this
one.
We
have
932
110
and
we
have
looks
like
HTTP
board
dat.
D
Let's,
let's
look
what
we
have
there
Carol
this,
this
IP
dat
and
we
are
getting
some
HTTP
response
and
looks
like
it's
a
actually
REST
API
and
in
free
loops
through
the
HTTP
response.
You
can
see
also
the
swagger
paths
we
can
actually
can
get
the
whole.
The
communication
to
all
the
possible
arm
passes
that
this
service
exposed.
So
let's
go
and
get
this
JSON.
You
come
in
JSON,
documentation,
swagger,
documentation,
okay,
it's
to
get
a
swagger
to
get
a
swagger
response,
but
to
get
that's
pretty
printed,
you
can
really
understand
what
they
are.
D
Okay,
so
pretty
printed
us
now.
We
can
get
all
the
methods
and
passes
this
faster
service.
This
REST
API
service.
We
have
users,
we
have
store
orders
and
we
have
some.
We
have
pad
so
let's,
let's
try
and
get
one
of
the
pad.
That's
here.
So
let's
try
to
Carol
it,
so
he
saw
their
flash
bad
/
gets
an
ID,
although,
although
int
to
this
fantasy
show
that
you
really
get
it
/
pad
/
Wan
that
ID
and
things
back
the
leaves
we
can
pass
yet
to
just
try
to
get
to
see.
D
If
we
have
access
to
do
this,
so
you
do
have
access,
we
get
the
first
patent
in
the
service.
So
actually
right
now
we
got
I'll,
go
back
to
the
to
the
architecture.
No
explain
what
we
saw
it's
actually
right
now
we
got
access
from
one
which
front-end
pod
service,
actually
almost
the
whole
cluster
and
I
think
so.
Some
of
the
ways
to
actually
to
mitigate
this
live
with
the
ideas.
D
The
time
job
before
is
to
try
and
understand
how
we
how
we
can
arm
how
we
can
narrow
or
minimize
the
the
blast
radius,
how
we
can
minimize
the
the
attack,
the
attack,
less
radius,
that
even
from
one
reach
pod,
that
might
might
happen
from
highly
sensitive,
highly
tactical.
Like
the
front
end
service
that
and
attack
everyone
get
to
the
whole
access
to
the
whole
posture.
So
of
course,
one
way
is
just
to
use
network
policies
just
disabled
the
communication.
D
So
in
that
case
we
actually
can
disable
completely
the
communication
between
the
front-end
and
sensitive
services.
They
don't
need
to
talk
to
each
other,
it's
more
complicated
it.
Arson
areas
usually
appear
in
real
time
and
real
world
real
world
applications
that
I
call
native
application.
Is
that
so
we
can't
completely
disable.
For
example,
we
can't
completely
disable
the
communication
between
the
content
and
the
radius
right
or
the
front
end,
and
the
paths
are
because
they
have
to
communicate
between
them.
D
So,
but
the
other
thing
that
we
would
like
to
minimize,
for
example,
or
to
get
visibilities
to
the
application
layer
to
layer.
Seven,
for
example,
watch
commands
are
running
or
what
what
actually
is
going
on
between
the
front
and
then
the
Redis
application
to
find,
for
example,
see
some
anomalous
behavior
that
someone
from
that
starts
running
the
Legion
on
my
database
or
trying
to
extract
all
the
keys,
which
is
not
a
normal
command,
front-end
application
grants
or,
for
example,
other
use
case
for
HTTP
service-
is,
for
example,
the
bastard.
D
D
C
So
we
have
here
a
kubernetes
cluster
that
we've
deployed
in
AWS
it's
running
about
50
different
deployments.
We
aggregated
them
to
applications
based
on
labels
that
are
attached
to
those
deployments
and
we
use
the
information
we
get
from
from
envoi
to
build
this
mass
of
service
to
service
communication.
C
So
here
we
see
our
nine
applications
and
we
can
zoom
in
into
a
specific
application.
This
one
is
the
HR
application.
It's
it's
built
out
of
five
micro
services.
We
can
see
how
many
instances
each
one
of
them
has
and
we
can
drill
one
level
deeper
into
a
specific
micro
service.
Let's
say
HR
travel
and
we
can
see
which
instances
it
has.
This
one
is
a
stateful
step,
so
the
pod
names
are
actually
meaningful.
C
So
here
we
see
the
arrow,
the
red
arrow
between
HR
travel
and
Finance
invoices,
which
suggest
that
we
don't
have
a
whitelist
rule
that
allows
this
this
chapter
and
obviously
we
can
change
the
behavior
to
say
whether
we
just
want
to
get
alert
or
we
can,
or
we
actually
want
to
block
this
traffic
and
an
n
voice
is
very
powerful.
In
that
sense,
it
not
only
provides
us
with
a
lot
of
information.
C
It
also
provides
us
with
the
authorization
primitives
that
are
required
to
enforce
an
access
control
policy
and-
and
of
course,
we
want
to
always
be
able
to
see
our
our
policy,
which
rules
will
define
some
could
be
service
service
rules.
Some
could
be
based
on
different
labels.
Some
could
be
Ingres
rules
identifying
ingress
IPS,
some
could
be
egress
rules
identifying
possible
domains
and
and
again
employee
is
a
great
a
tool
to
help
us
actually
implement
those
rules
in
in
our
data
plane
and,
of
course,
artifacts
can
be
imported.
C
The
workload
definitions
can
and
should
be
imported
from
either
kubernetes
or
east
EO,
depending
on
what
you
have
deployed.
Obviously,
if
you're
deploying
east
EO
envoi
is
is
given,
the
mixer
is
already
the
natural
point
of
getting
all
that
information
regarding
traffic
and
and
policy,
and
then
it's
just
a
matter
of
connecting
it
to
a
dashboard
to
get
that
visibility
or
just
to
build
periodical
reports.
I
think
that's
it
for,
for
us
will
be
very
happy
to
answer
some
questions
at
this
point.
A
Thank
You
hime
and
thank
you
yah
Guinea,
that
was
great
I,
think
there
were
a
few
questions
in
chat
that
were
answered.
I
think
there's
a
couple
that
are
still
remaining
one
question
from
Satish
was:
can
the
same
principles
be
applied
to
legacy
applications
such
as
on
Prem,
I?
Guess
he's
referring
to
non
containerized
applications
or
VMS,
so.
C
I
think
you
have
to
you,
have
to
at
least
be
able
to
extend
the
same
principles
to
communication
between
your
new
cloud
native
application
and
your
legacy
applications.
So,
even
if
you
have
your
security
controls
already
in
place
for
your
legacy
applications,
they
will
not
be
as
effective
when
you
need
to
start
allowing
access
for
micro
services
to
your
databases,
your
ERP
or
any
other
legacy
system,
and
so
the
principle
is
the
same.
C
The
proxy
and
the
sidecar
approach
actually
works
very
well
on
VMs
or
bare-metal.
As
long
as
you
make
sure
that
traffic
is
routed
through
the
proxy,
it
can
have
exactly
the
same
functionality.
Some
things
are
actually
much
easier
in
legacy.
Environment
like
identity,
bootstrapping
and
actually
a
test
attestation
of
identity
is,
is
a
lot
easier.
D
C
Not
not
really
I
think
the
nice
thing
about
kubernetes
is
that
it
has
a
very
similar
approach
to
handling
both.
So
we
have
the
concept
of
a
pod
and
and
in
in
the
cloud
native
approach,
even
if
a
part
is
stateful,
we
still
expect
it
to
be
able
to
go
down.
Sometimes
we
have
redundancy
in
place.
We
have
locality
of
state,
so
the
same
principles
in
changing
in
terms
of
the
outbound
traffic
for
a
stateful
container
apply
same
way
as
they
do
for
stateless
containers.
Thank.
C
So
we
don't
see
ourselves
as
a
competition
or
a
different
implementation
arson.
What
we've
been
working
on
actually
works
really
well
with
a
steal.
So,
as
I
mentioned,
if
you
have
we
still
deployed,
we
don't
do
anything
in
the
data
plane
or,
and
we
integrate
with
the
stos
control
plane
to
create
all
you
need
in
terms
of
visibility
and
policy
management
for
users
who
haven't
decided
to
use
a
skill.
Yet
again,
our
solution
is
similar
in
the
way
we
approach
security
to
live.
A
C
So
obviously,
as
long
as
we
have
a
trust
chain,
so
we
can
have
access
to
the
root
of
trust
for
those
back-end
services.
Then
there
is
no
problem
in
defining
a
routing
rule
that
says
that
egress
traffic
to
a
specific
domain
should
be
encrypted,
and
then
it's
just
a
matter
of
adding
a
client
certificate
which
can
be
very
helpful
for
some
of
the
back-end
services
to
identify
the
the
principal
of
the
client
that
is
contacting
them.
C
So
he
still
does
not
use
speak
Li
it
they
have
their
own
way
of
managing
certificates
and
anticipations
envoy,
of
course,
works
great
with
spiffy,
actually,
all
the
the
certificates,
the
format,
the
SVD
format
for
identity
in
the
certificate
is
used
in
East
EO
and
is
natively
supported
in
envoy.
So,
yes
and
boy
works
great
with
50.
C
A
C
So
spiffy
is
not
used
for
authorization.
It's
it's
a
way
to
distribute
identities
that
can
later
be
used
for
authentication
and
on
top
of
authentication.
You
can
build
authorization
if
your
authorization
is
actually
now
just
configuring
invoice
authorization
based
on
identities.
Those
identities
are
speed.
As
I
said
there
s
width,
which
is
the
format
that
spiffy
promotes
for
identity,
but
if
you're
looking
at
kind
of
spire,
which
is
the
reference
implementation
of
spiffy,
that
one
is
not
used
in
each
year,
yeah.
A
C
A
And
if
there
are
no
more
questions,
we'll
close
here
thanks
very
much
Haim
thanks
very
much
Evgeny
that
was
very
interesting
and
I'm
sure
there's
more
to
come
on
this
important
topic.
We
look
forward
to
seeing
you
on
a
future
CNC
at
webinar.
The
links
and
the
recording
will
be
posted
and
have
a
good
day
thanks
for
joining
by.
Thank.