►
Description
Aporeto’s Cloud Native Security solution works through authentication, authorization, and encryption for all of a distributed application’s components. It generates a cryptographically-signed identity certificate for every application component orchestrated by OpenShift and allows interactions between those components if there is a policy that explicitly allows it. This whitelist security model is simple because it does away with the massive complexities of configuring the different segmentation schemes that would otherwise be required to achieve the same ends. In this briefing, Amir Sharif of Aporeto will give an overview of the solution and demonstrate using with applications deployed on OpenShift, explain the benefits and implications of this security model
A
Welcome
everybody
to
yet
another
OpenShift
Commons
briefing.
We
have
Amir
Sharif
with
us
from
up
there,
Perico
I'm
sure,
I'm,
saying
it
wrong.
Every
time
I
say
it.
I
I'd
say
a
different
variation
on
it,
but
we're
really
pleased
to
have
them
here.
They
have
a
unique
cloud
native
security
offering
and
the
unique
perspective
on
implementing
security
for
five
native
applications
and
systems.
So
I'm
gonna,
let
Amir
introduce
himself
the
format
for
this
session.
As
always,
is
you
can
ask
questions
in
the
chat?
A
B
You
Diana
and
thank
you
for
giving
a
chance
to
talk
at
the
open
shift.
Commons
briefing
as
Diane
said,
my
name
is
Amir
Sharif
I'm,
the
co-founder
of
aparato
and
aparato,
is
a
cloud
native
security
company.
Basically,
our
focus
is
to
look
at
distributed
workloads
across
any
cloud
on
any
infrastructure
and
OpenShift
is
a
big
focus
for
us.
B
In
this
talk,
I
will
discuss
the
challenges
that
we're
facing
with
going
cloud
native,
there's
challenges
and
I'm
going
to
actually
highlight
a
customer's
environment
and
talk
about
the
problems
that
we
have
encountered
there
and
that's
going
to
be
common
across
many
other
customers
and
then
talk
about
how
we
approach
cloud
native
security.
So
with
that,
let
me
get
started
and
let
me
paint
the
scene-
and
this
slide
basically
describes
the
transition
that
we're
making
from
servers
to
a
service
world
with
VMs
and
containers
being
way
way
points
along
the
way.
B
The
point
is
that,
as
we
went
from
service
to
VMs
the
number
of
endpoints
on
the
network
increased
tenfold
or
by
an
order
of
magnitude
and
by
their
nature,
VMs
are
more
transient
than
servers.
Therefore,
the
change
frequency
also
went
up
by
an
order
of
magnitude.
Now
we
are
getting
to
inside
a
containers
world
and
again
we're
seeing
at
least
an
order
of
magnitude
increase
the
number
of
endpoints
in
the
networks,
because
the
number
of
contain
that
could
fit
inside
a
VM
or
inside
the
server
and
correspondingly
they
change
frequency.
B
Again,
it's
going
to
get
by
an
order
of
magnitude
and
projecting
the
future.
We
can
see
the
same
thing
happening
the
service
world
now
by
saying
server,
less
I'll
grooming.
All
we're
saying
is
that
we're
abstracting
the
way
containers
and
what
containers
are
doing
is
abstracting
the
way
the
OS,
whether
they're
running
on
a
VM
or
a
bare-metal
server,
and
the
VMS
are
abstracting
away
the
server.
So
by
going
up
the
stack
nothing's
actually
disappearing,
except
we're
abstracting
away
complexity.
B
That
abstraction
allows
us
to
have
more
working
units
in
the
network
and
have
a
more
dynamic
environment.
Now,
here's
the
rub
at
when
we
are
focusing
on
security.
From
a
networking
perspective,
we
are
solving
a
quadratic
problem,
you're
solving
an
N
squared
problem,
so
hold
up
your
hand,
and
you
have
five
digits
on
your
hand
and
the
number
of
connections
that
you
can
make
from
every
point.
Every
point
is
ten:
that's
basically
N
squared
minus
n
over
two,
so
you're
solving
an
N
squared
problem.
B
Whenever
you're
trying
to
calculate
the
number
of
connections
between
points
and
as
n
gets
larger
as
we're
showing
here
across
the
x-axis
there,
the
calculation
becomes
harder
and
harder,
especially
as
you
have
to
do
it
more
frequently,
because
the
change
frequency
is
going
up.
So
what
we
were
doing
or
what
we
are
doing
in
the
lower
range
of
the
market
with
servers
of
VM
is
where
we
give
them
beautiful
names.
I
mean
effectively
they're
pets,
they're,
not
nearly
as
dear
as
as
Diane's
dog,
but
she's
adopting
right
now.
But
you
know
we
do
give
him.
B
B
B
You
want
to
work
on
your
private
data
center
and
ideally
it
should
be
part
of
the
DevOps
pipeline,
meaning
that
the
security
layer
should
be
invisible
to
the
developer
to
the
developer,
but
have
the
ability
to
ingest
the
application,
intent
and
know
what
what
it's
trying
to
do
so
when
their
cattle
goes
wild
when
the
application
goes
wild.
It
provides
the
right
level
of
security
for
it.
B
Let's
talk
about
the
cloud
native
application,
the
way
we're
building
cattles
and
this
when,
when
people
talk
about
what
a
cloud
native
application
is,
this
is
the
beautiful
pristine
picture
that
they
think
about.
You
know
you
have
some
services
talking
to
each
other
and
and
some
load
balancer
maybe-
and
there
is
some
data
back-end.
In
fact,
what
the
application
tends
to
look
like
is
something
like
this.
The
application
typically
has
to
be
available.
It
has
to
be
deployed
in
multiple
availability
zones.
You
have
to
do
some
sort
of
database
replication.
B
The
way
you
do
this
is
so
the
application
is
resilient
to
failures
in
a
cloud.
So
if
one
available
zone
goes
away,
you
have
other
availability
zones
available
to
to
take
care
of
it.
You
usually
have
to
interface
with
some
sort
of
legacy
infrastructure,
some
partner
network,
some
external
stuff,
and
the
picture
that
you're
seeing
here
is
actually
from
a
current
customer
that
we're
working
with
who
is
running
open
shift
to
orchestrate
their
workloads
in
three
different
availability
zones
and
GCP.
B
Now,
as
I
mentioned,
the
number
of
endpoints
inside
the
network
is
getting
higher,
so
the
freckles
that
you
see
instead
of
clouds,
represents
that
containers
are
coming
and
going
and
what
this
customer
has
done
and
this
patter
has
been
repeated
across
multiple
customers.
What
they're
doing
in
order
to
provide
security
for
this
type
of
environment
is
the
following:
it's
a
mess,
basically
they're
overlaying
an
SDN
either
some
some
open
sore
variant
of
SDN
to
stitch
together
different
V
pcs.
They
have
virtual
appliances
running
again.
There
are
access
control
lists.
B
They
just
had
a
very
complex
and
fragile
and
fundamentally
insecure
environment
that
allowed
somebody
to
get
in
and
exfiltrated
a
lot
of
data
and
harm
a
lot
of
consumers.
That's
the
problem!
Now
the
question
isn't
that.
Why
do
we
have
such
a
complexity
inside
the
cloud?
And
the
answer
is
that
basically
we're
trying
to
solve
for
different
types
of
problems,
their
segmentation,
that
we
have
to
do?
There's
encryption,
there's
an
enforcement.
There's
secrets
management.
B
So
it's
up
to
the
customer
to
kind
of
cobble
stuff
together
and
good
luck
to
you
as
you
go
through
now.
The
question
is
that:
why
do
we
have
this
again,
you
know
killing
the
onion
now.
Why
do
you
have
this
complexity?
What
we
get
into
is
this
is
the
way
the
Internet
is
designed.
The
internet
was
designed
to
connect
all
points
to
everything.
That's
the
nature
of
TCP
traffic,
everything's
supposed
to
be
discoverable
and
open,
Network
great
it
works,
but
as
the
number
of
nodes
gets
larger,
you
know.
B
I
talked
about
the
N
squared
problem,
as
a
number
of
nodes
gets
larger.
The
exceptions
that
you
have
to
create
for
preventing
certain
notes
to
talk
to
each
other,
there's
our
that's
the
isolation
that
you
do.
It
becomes
more
and
more
difficult,
so
as
a
number
of
as
in
a
world
where
everything's
supposed
to
talk
to
each
other
and
you're
trying
to
prevent,
prevent
bad
actions,
the
number
of
exceptions
keeps
getting
exponentially
higher.
So
what
we
ultimately
want
is
a
white
white,
the
security
model,
where
we
know
what
the
application
intent
is.
B
We
know
what
we
what
we
should
do
in
order
or
what,
how
the
application
should
behave
out
in
a
while,
and
to
do
that,
you
need
to
have
basically
three
core
concepts:
one
is
identity.
What
is
my
application
doing?
That's
that's
that's
effectively,
partly
to
know
what
what
component
the
application
is.
Second,
we
need
to
have
policy
and
the
policy
is
the
application,
intent
and
organizational
intent.
B
What
what
should
the
applications
be
doing
in
the
wild
as
it
is
supposed
to
be
doing,
and
what
is
the
organizational
posture
for
security
as
dedicated
by
corporate
guidelines
or
by
regulatory
requirements?
And
third,
you
have
to
have
some
sort
of
enforcement.
So
let
me
talk
about
how
a
pareto
solves
the
the
identity
problem
and
then
talk
about
how
we
approach
policy
and
enforcement.
So,
basically
think
about
your
distributed
application
running
and
oprah's
OpenShift
in
the
cloud
somewhere,
there's
a
service
that
you
have
and
it's
trying
to
access
some
resource
when
that
service
comes
up.
B
There
is
a
yama
file,
that's
associated
with
that
with
your
entire
application
and
that
the
mo
file
provides
some
metadata
as
to
what
that
service
is
this,
but
we
can
also
correlate
what
openshift
is
doing
to
what
systemd
is
doing
and
say:
okay,
we
and
derive
certain
information
like
who
is
running
this
application.
Where
is
it
running?
Is
it
running
an
amazon
eastern
amazon
west,
for
example,
what's
being
run?
Is
that
Redis
is
it?
B
Is
it
said,
toss
and
what's
what's
being
run
in
this
particular
obligation?
The
metadata
is
what
comes
from
the
ammo
file,
as
I
mentioned,
an
additional
key
value,
pairs
and
terms
of
reputation
that
comes
from
image
scanners
that
provide
the
vulnerabilities
of
that
particular
service.
That's
come
up
all
that
we
call
a
trust
profile,
let's
think
of
it
as
a
dynamic,
three
dimensional
FICO
score
for
a
particular
service.
B
That's
come
up
and
at
this
point,
because
we
have
noticed
that
the
services
come
up
and
it's
talking
to
certain
resources,
because
that's
when
that
describe
in
the
application,
the
Ambo
file,
we
spray
the
stress
profile
across
everything,
so
anything
that
comes
up.
That's
relate
to
have
that
application
that
we
want
to
secure
now
has
an
identity
and
I'll
get
into
the
mechanics
of
that
a
little
bit
deeper
in
a
presentation
now
that
now
that
we
have
the
item,
maybe
the
next
question
is:
how
do
we
allow
the
service
to
connect
to
a
particular
resource?
B
B
Our
inspiration
for
policy
was
the
English
language,
where
you
have
a
sentence
that
has
a
subject
or
verb
and
an
object,
and
in
our
case
the
verbs
are
pretty
simple.
There
are
things
like
allow,
read,
encrypt
dropped,
connect
so
forth,
and
so
on.
A
finite
set
of
very
well
defined
verbs
that
we
work
with
and
in
terms
of
subjects
and
objects.
B
Basically,
we
are
looking
at
a
key
value
pairs
that
that
defined
the
trust
profile
and
in
order
to
define
policy
for
the
subject
in
the
object,
the
thing
that
does
the
action
and
the
thing
that
receives
the
action.
What
we
do
is
do
set
operations
and
the
key
value
pairs.
So
to
illustrate
this,
if
I
want
to
have
a
very
permissive
policy,
I
say,
say:
a
write.
A
sentence
like
environment
equals
production
can
connect
to
environment,
equals
production.
So
anything
with
that
tag.
B
End
vehicles
prod
can
now
talk
to
itself
that
it's
a
permissive
that
policy,
if
I,
want
to
get
more
restrictive
I
would
write
a
policy
like
my
payroll
application.
Production
can
talk
with
confidential
data
and
production
as
long
as
my
connection
is
encrypted,
that
that
becomes
my
policy
and,
as
you
can
see,
that
with
these
set
operations,
I
have
further
narrowed.
The
scope
of
the
subject
of
the
object
and
I
can
continually
narrow
down
the
scope
as
much
as
I
want
to
down
to
a
level
of
indefinite
subject.
B
So
when
you
look
at
our
platform
and
what
the
operator
does
you
know
between
a
service
and
a
process,
we
do
a
authentication.
We
do
authorization
because
we're
a
proxy
between
the
notes.
We
can
transparently
encrypted
communication
between
the
nodes
and
we
also
do
monitoring
and
enforcement.
The
reason
we
can
do
monitoring
is,
we
know,
what's
tried,
trying
to
connect
to
what
and
we
can
map
it
and
enforcement
is
basically
the
application
of
the
policy
to
effectively
we're
doing
application
segment.
B
Segmentation
secrets,
management's,
encryption
and
real
time,
monitoring
and
enforcement
and
taking
us
back
to
this
slide.
What
we've
tried
to
do
is
provide
a
holistic
solution
that
addresses
the
security
needs
of
a
cloud
native.
The
application
has
orchestrated
by
something
like
open
chef
in
a
very
unified
way
and
a
very
simple
way
so
in
in
a
slide.
B
What
we
do
basically
is
take
any
application
and
distribute
an
application
and
any
infrastructure,
and
you
may
have
services
and
external
external
services
and
files
basically,
and
we
put
a
protective
layer
around
each
one
that
this
that
defines
what
can
connect
to
what
and
encrypt
optionally
encrypt
the
communication
between
the
notes,
simple
scalable,
secure.
That's
what
we
do
so
at
this
point.
B
I
want
to
get
a
little
bit
deeper
into
the
mechanisms
of
how
we
do
things
so
that
you
have
some
appreciation
of
of
why
this
is
unique
and
way
that
radically
simplifies
our
world
and
I'll.
Talk
about
some
use
case
that
we
handle
specifically
with
OpenShift
or
either
kubernetes
clusters,
so
imagine
having
two
different
clusters
with
micros.
This
could
be
pods
with
micro-services
up,
there's
a
source
and
a
destination.
That's
coming
up
and
there's
a
state
information
that
each
side
has
at
the
top.
B
We
have
you
know
the
production
environment,
the
application
is
web
and
my
images
nginx.
Those
are
my
key
value.
Pairs
at
the
bottom.
I
have
other
attributes
application
time
because
production
and
instances
the
database,
for
instance.
Now
you
see
my
policy
down
the
bottom.
The
policy
says,
accept
the
connection
from
application
equals
web
in
a
production
environment.
So
that's
what
the
policy
will
allow
us
to
do
so,
on
top,
we
do
have
a
web
application
in
a
production
environment,
and
one
of
these
guys
tries
to
attempt
a
node
or
note
in
their
cluster
below.
B
So
what
he
does
is
sends
a
request
that
request
goes
out
as
a
TCP
syn
packet,
so
the
syn
packet
when
it
goes
out
at
this
point
we
intercept
it
and
we
provide
the
trust
profile
as
payload
on
a
syn
packet.
So
now
you
have
a
cryptographically
signed
identity
associated
with
the
sim
packet.
That's
going
out
as
such
we're
not
using
the
IP
address
as
the
identity
we're
actually
using
a
much
more
sophisticated
set
of
attributes
associated
with
the
workload
that
becomes
the
identity.
Then
the
TCP
packet
goes
off.
B
At
this
point,
we
can
provide
transparent
encryption,
basically
without
the
application.
Knowing
that
is
talking
in
an
encrypted
language,
we
can.
We
can
provide
that
encryption
and
then
decrypt
it
in
a
farside,
simple,
easy
and
and
off
we
go
so
the
application
isn't
clear
that
the
rest
of
the
world
cannot
read
it
and
that
makes
a
developer's
job
a
lot
easier.
Now,
on
the
far
side,
we
asked
two
questions:
number
one
is
when
the
sim
packets
coming
is,
is
it
signed?
There's
a
it
does
have
an
identity
piece
to
it.
B
If
it's
no,
we
dropped
the
packet
and
we
don't
allow
the
communication
to
begin.
If
it
is
signed,
then
we
ask
the
question:
is
there
a
policy
that
allows
the
sender
to
talk
to
the
receiver
and
if
the
answer
is
No
again
we
dropped
a
packet
and
a
connection
is
never
established.
If
the
answer
is
yes,
then
we
validate
based
on
policy
and
we
allowed
the
sim
packet
to
go
forward.
It
hits
a
target.
B
The
target
at
this
point
responds
with
a
symmetric
action,
and
then
you
have
mile
at
a
mutually
established
trust
between
the
sender
and
receiver.
They
both
know
who
they
are,
and
that
can
happen
regardless
of
where
they
are
in
a
network,
so
they
can
be
on
the
same
subnet.
They
can't
be
on
the
same
VLAN
tour.
They
can
be
on
two
different
clouds
across
across
the
internet.
The
point
is
that
we
actually
do
not
use
IP
as
a
proxy
for
identity.
B
We
actually
use
a
much
richer
set
of
attributes
that
allows
us
to
apply
security
policy
and
a
much
more
granular
level.
So
that's
at
a
high
level.
What
the
mechanism
looks
like.
Let
me
know.
I
should
also
add
that
when
you
do
the
key
differences
that
when
you
do
add
additional
instances,
this
is
an
linear
operation.
It's
not
a
quadratic
operation,
because
all
we
care
about
is
the
identity.
We
don't
have
to
calculate
the
entire
route
and
exceptions
and
firewall
rules
and
so
forth.
So
we
are.
We
are
offering
an
o1
space
or
linear
space.
B
Let's
talk
about
the
few
use
cases
with
with
open
shift
and
how
we
can
handle
them.
So
imagine
having
an
open
shift
cluster
running
and
the
first
use
case
is
open
shift,
providing
its
native
Network
policies
to
operate,
oh
and
after
rendering
them
as
services,
so
basically
a
fully
compatible
model.
So
what
open
shift
does
is
provide
the
network
causes
to
operate?
Oh,
what
a
Pareto
returns
its
policy
that
makes
that
environment
secure,
and
at
this
point
we
actually
haven't
added
much
value.
B
We
have
just
been
fully
compatible
and
provided
a
Pareto
security
based
on
network
policy.
So
we're
in
complete
sync
now
at
the
next
level
is
we
can
actually
augment
Network
securities
with
additional
capabilities
that
that
Frodo
has
using
the
key
value
pair
matching
and
the
policy
language
that
we
have
so
network
policy
is
going
that
/
at
this
point
provides
a
super
set
of
security
policies
go
above
what
OpenShift
can
do
or
kubernetes
can
do
to
provide
a
much
richer
context
and
and
the
third-
and
this
gets
more
interesting-
there
is
egress
network
policy
support.
B
What
operator
allows
you
to
do
is
also
define
ingress
policies,
egress
rather
egress
policy.
So
when
a
when
a
pod
inside
an
open
shift,
cluster
wants
to
communicate
to
the
outside
world.
That
communication
can
also
be
police.
It's
not
just
rejecting
incoming
traffic
is
making
sure
that
when
the
pie
was
communicating
out
to
the
world,
it's
it's.
It's
paired
with
a
certain
set
of
rules
and
building
on
top
of
that
is.
We
do
provide
support
for
external
services.
So
let's
say
that
you
have
this
pod.
B
What
aparato
allows
the
pot
to
do
or
allows
allow
you
to
do
is
to
provide
sanction
access
to
various
resources.
Let's
do
let's
say
that
you're
doing
a
Google,
Maps
mashup
in
that
case,
that
would
be
Google.
Maps
would
be
an
external
resource
and
it
can
say
that
this
particular
pod
or
this
particular
cluster,
has
access
to
this
particular
external
service.
And
again,
that's
that's
a
that's.
A
value.
Add
that
we
can
provide
to
the
kubernetes
distributions
now
taking
a
step
back,
I.
B
Think
sort
of
the
the
key
value
prop
that
we
can
provide
for
kubernetes
clusters
is
multi
availability
zone
security,
similar
to
the
first
like
that
I
provided
and
imagine
you
have
a
private
data
center
run
where,
if
somewhere
and
you're
running,
go
up
and
shift
on
AWS
and
you
have
DL
bees
and
netting
and
so
forth
with
much
of
a
bunch
of
firewalls
across
now.
If
you
are
trying
to
provide
communications
or
application
security
across
this
environment,
it's
highly
complex
and
basically
it's
going
to
be
mind-boggling,
very,
very
difficult,
difficult
to
maintain.
B
Partly
it's
because
you
are
speaking
different
languages
inside
your
data
center
and
what
the
cloud
service
provider
is
doing
with
a
Pareto.
Basically,
you're
defining
a
policy
he's
saying
that
that
particular
pod
running
inside
my
data
center
can
talk
to
another
particular
pod
running
the
AWS
and
as
long
as
the
two
can
ping
each
other,
the
connection
is
established.
That's
it
you
don't
have
to
worry
about
providing
firewall
rules.
You
don't
have
to
worry
about
losing
state
as
you
go
through
load,
balancers,
so
forth,
and
so
on.
B
It's
a
simple
statement
that
says
a
can
talk
to
be
regardless
of
location
because
IP
address
does
not
matter
to
us
and
that
security
services
provided,
regardless
of
where
the
application
is
residing.
So
going
back
to
this
big
messy
picture
that
I
provided
up
front,
and
this
is
a
common
architecture
that
we
see
with
all
this
complexity.
B
Basically,
what
you're
getting
is
a
reduced
attack
surface
at
verifiable
security
posture,
and
you
can
actually
go
back
and
forth
at
any
time
because
it
can
rip
out
a
lot
of
the
complexity
within
the
network.
You
will
get
a
lower
cost
that
can
happen
at
any
cloud
and
we
do
scale
pretty
well.
I,
don't
want
to
state
the
numbers
and
stock,
but
the
numbers
are
quite
quite
nice.
So,
looking
at
our
architecture,
we
do
talk
about
identity,
we
have
analytics
and
management
and
they
have
multiple
pluggable
enforcers.
B
B
It's
I
think
we
just
hit
more
than
50,000
downloads
today,
actually
as
of
last
month,
and
the
the
solution
within
itself
is
useful
for
developers
to
provide
connectivity
rules
and
not
have
to
worry
about
any
sort
of
infrastructure
complexity,
but
you
you
now
have
a
broader
picture
of
what
is
it
that
we
do
and
all
that
is
exposed
in
a
UI
like
this
and
I
would
encourage
everybody
to
actually
go
and
sign
up
for
a
free
account.
That's
free
account.
It's
console
that
operator
calm
and
then
connect
your
OpenShift
workload
to
it.
B
Let
us
ingest
the
network
policies
and
then
experiment
with
with
how
we
write
policies
go
through
our
use
cases
and
our
tutorials
and
see
how
much
simpler
and
more
security
application
can
get
me
with
a
Pareto
in
a
cloud
native
environment,
especially
orchestrated
with
a
platform
like
the
open
shift,
and
with
that
we
come
to
the
end
of
the
presentation.
Diane
I
think
we
did
it
and
half
an
hour.
Less
I
talk
pretty
fast,
though
let
me
know
if
you
have.
A
B
An
excellent
question
so
when
we
do
provide
identity
and
do
a
policy
lookup
between
the
two
nodes
and
this
transaction
that
I
described,
we
do
per
pay
increase
latency.
That
Lexi
is
currently
on
the
order
of
three
milliseconds.
So
it's
pretty
fast
and
it's
once
per
connection.
So
once
the
TCP
session
is
established.
Basically
it
can
happen
at
wire
rate.
B
You
there's
no
encryptions
is
going
on
and
if
it's
encrypted
we
encrypt
the
entire
data
path
and
then
we
dump
it
to
TCP,
and
the
performance
at
that
point
is
actually
slightly
better
than
SSL,
but
I
would
say
it's
on
par
with
SSL,
so
yeah
at
the
startup.
There
is
a
hit
of
about
three
milliseconds
and
they'll
get
further
enhanced,
but
at
the
runtime
it's
a
dwyer
rate
or
on
par
with
itself.
A
That's
actually
on
pretty
impressive,
so
tell
me
a
little
bit
about
your
roadmap.
What
are
the
other
things
that
you
think
are
coming
or
you're
gonna
bring
I
know
you've
open-source
trim
from
from
a
pyrene
pyrene
Yankee.
You
know
I'm
telling
you
these
things,
we're
gonna
work
on
some
of
my
pronunciation
of
these
things.
I
apologize
for
that,
but
50,000
downloads
is
pretty
impressive,
and
so
that's
that's
great,
and
it's
not
that
I'm
going
to
tell
you
to
open-source
your
entire
project
or
sometimes
I
I
might
push
you
that
way.
B
B
That's
an
operational
model
that
allows
brand
new
applications
to
talk
with
older
applications
and
have
a
consistent
security
policy.
I
don't
want
to
get
into
a
lot
of
details
in
that,
but
the
work
is
to
make
sure
that
we
take
cloud
native
workloads
and
make
them
well-suited
for
the
enterprise
and
more
acceptable.
A
And
so
the
enterprise
thing
is
very
important:
I
know
for
everybody
in
the
kubernetes,
in
the
open
ship
space
as
well.
So
this
and
I
apologize
if
I
missed
this.
When
you
were
talking
before
this
sounds
like
it's
a
hosted
solution,
or
is
this
something
that
people
can
use
on
on-site
on
their
private
clouds,
I.
B
Did
not
mention
that
you
know
that
message
miss
it,
but
basically
there
are
two
models:
one
model
as
applied
by:
let's
slide,
where
I
put
the
try
it.
That
is
a
hosted
model
where
you
run
your
workload
wherever
you
want
to
run
and
the
enforcer
that
runs
on
your
operating
system,
then
dials
back
to
a
Pareto
and
provides
a
security
service,
and
then
you
can
manage
the
security
service
on
effort.
Comm,
that's
model
number
one.
B
What
we
see
happening
is
people
start
with
a
hosted
solution
and
because
of
various
concerns
they
want
to
have
their
own
hosted
solution,
meaning
that
they
take
a
Pareto
and
they
install
it
in
their
own
private
cloud.
Where
would
that
may
be?
Maybe
a
hosted
environment
and
GCP
or
AWS,
or
it
may
be
inside
their
private
data
center?
And
at
that
point
it's
exactly
the
same
operational
model
except
we
do
not
give
the
customer
data.
The
customer
has
ron,
has
their
own
analytics
engine
and
they
generally
feel
more
secure
that
in
that
environment,
well,.
A
It's
great
that
you
have
both
options
available,
so
I'm,
looking
and
I'm
thinking,
you've
done
a
pretty
good
job
covering
off
all
the
bases.
I.
Really
some
of
the
intro
slides
were
really
great.
From
from
my
perspective,
I,
like
the
four
pillars
of
a
security
perspective,
a
lot
and
I
really
do
think
we
did
a
great
job
of
explaining
the
pets
and
cattles
and
the
beginning,
so
I'm
definitely
I've
seen
it
done
in
a
lot
of
different
ways
and
I
think
you
did
an
awesome
job
of
explaining
the
security
challenges.
A
There,
though,
thank
you
very
much
and
is
there
anything
else,
you'd
like
to
add
and
maybe
go
back
to
your
very
first
slide,
because
that's
the
one
that
had
your
email
address.
If
people
want
to
get
a
hold
of
you
and
if
they're
after
and
we'll
leave
it
at
that
and
I
will
try
and
get
this
up
with
all
the
links
and
a
link
to
the
the
open
source
project
as
well.
So
thanks
again
I'm
here
for
joining
us
today
and
we
look
forward
to
hearing
more
from
you
in
the
future
as
well.