►
Description
The distributed nature of Kubernetes has turned both legacy infrastructure and traditional cybersecurity approaches on their heads. Organizations building cloud-native environments in their own data centers grapple with operationalizing and scaling Kubernetes clusters, and then ensuring system-wide security from the infrastructure layer all the way up to each container.
In this webinar, you’ll hear from two cloud-native experts in infrastructure and security who will offer up valuable insights on:
- How containerized applications use compute, storage, and network resources differently than do legacy applications
- Why hyper-converged infrastructure is suited for Kubernetes
- How a Kubernetes stack should be instrumented for observability
- Best practices for implementing system-wide security for multi-cloud Kubernetes
Presented by Nutanix and Sysdig
Presenters:
Sylvain Huguet, Sr. Product Manager - Karbon/Kubernetes @Nutanix
Loris Digioanni, CTO & Founder @Sysdig.
A
Okay,
let's
get
started.
Thank
you.
Everyone
for
joining
us
today
for
today's
cncf
webinar,
critical,
dev,
sec,
ops
considerations
for
multi-cloud
kubernetes.
My
name
is
jerry
fallon
and
I
will
be
moderating
today's
webinar.
I
would
like
to
welcome
our
presenters
today:
slovan
hooget
senior
product
manager
of
carbon
and
cloud
native
solutions
at
nutanix
and
loris,
dijani,
cto
and
founder
of
system,
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
There
is
a
q,
a
box
at
the
bottom
of
your
screen.
A
A
Please,
please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
the
code
of
conduct.
Please
be
respectful
of
your
fellow
participants
and
presenters.
Please
note
that
the
recording
and
slides
will
will
be
posted
later
today
to
the
cncf
webinar
page
at
cncf.
Dot,
io,
slash
webinars.
B
B
I
have
a
personal
background
more
as
an
end
user.
It's
probably
my
first
time
as
a
in
a
software
development
world.
So
I
come
more
from
the
technology
side
of
things
more
of
the
practitioner
side
and
today
I
have
the
great
pleasure
and
honor
to
co-present,
with
loris
from
sisdig,
so
loris
take
it
from
there.
C
Thank
you.
Yes,
my
name
is
loris
dejani,
I'm
cto
and
founder
of
sysdig
says
dig
is
my
second
company.
My
first
company
was
called
case
technologies
and
was
the
company
behind
the
wireshark
network
analyzer,
so
I've
been
in
open
source
and
security
and
visibility
for
essentially
my
whole
career.
Recently.
C
Today
we
are
going
to
talk
about
the
cops
we
are
going
to
talk
about
the
security
we
are
going
to
talk
about
cloud
native,
but
let's
start
by
the
high-level
trend
right
and
the
a-level
trend
definitely
is
towards
software.
Software
is
becoming
more
and
more
important
in
every
industry.
Every
vertical
every
enterprise
nowadays
is
an
enterprise
software.
Definitely
there
are
trends
that
are
like
influencing
the
old
world.
C
Their
planet,
iot,
artificial
intelligence,
are
examples
of
these
trends
and
in
every
industry,
even
the
more
classical
industries,
even
like
brick
and
mortar
industries
that
have
to
do
with
the
physical
world,
and
nowadays,
software
really
is
the
difference.
The
differentiator
and
what
determines
the
success
of
failure
of
a
company
of
a
business
in
the
long
term
and
software
is
becoming
more
and
more
containers.
C
Software
is
becoming
more
and
more
orchestrated,
modern
microservice
based
applications.
Let's
talk
about
containers.
First
of
all,
I've
been
following
this
industry.
Essentially
since
the
beginning
since
when
docker
started
the
container
revolution
around
six
or
seven
years
ago,
and
it
was
very
interesting
to
notice
how
containers
initially
were
perceived
just
as
a
lighter
form
and
more
lightweight
form
of
virtualization
right,
so
they
were
considered
alternative
to
virtual
machines.
C
They
quickly,
thanks
to
the
fact
that
the
packaging
of
a
container
is
well
known
and
transportable
and
can
be
used
to
run
containers
in
multiple
places.
They
quickly
became
the
basis
of
continuous,
continuous
integration
of
ci
cd
and
really
they
sort
of
revolution.
The
way
we
all
do:
ci
cd
but
the
real
power.
C
On
top
of
this
infrastructure
policies
like
centralized
policies
with
the
open
policy
agents,
opa
network
policies,
in
conjunction
with
networking
frameworks
like
calico,
for
just
networking
and
in
layer,
3
segmentation
image
scanning
with
anchor-
and
they
all
you
know,
like
ci,
cd
kind
of
protection,
admission
controllers
to
be
able
to
maybe
in
conjunction
with
tools
like
copper,
to
control.
What
goes
in
your
cluster
and
runtime
like
filtering
and
protection,
like
both
security
policies
of
second
profiles,
this
to
me
looks
like
a
really
rich,
powerful
ecosystem.
C
That
is
all
of
the
components
or
most
of
the
components
that
you
were
used
to.
You
know
like
find
from
essentially
fragmented
commercial
vendors.
They
it's
it's
essentially
all
in
the
same
place
and
all
in
the
same
ecosystem,
and
this
is
very
powerful.
The
reason
why
open
is
powerful
in,
in
my
opinion,
or
at
least
one
of
the
reasons,
is
that
at
this
point
we
can
create
consistencies.
We
can
create
mutual
benefits.
We
can
create
harmonization
among
these
different
tools
and
make
them
essentially
work
together
in
a
stack
which
is
very
powerful.
C
It
means
less
vendor
lock-in,
but
it
also
means
much
more
value
and
much
more
innovation
in
the
ecosystem
and
for
the
final
users.
Also,
this
also
this
means
potentially
more
complexity.
Right,
if
you
look
at,
if
we
look
at
all
of
these
pieces,
I
was
saying
you
know:
falco
is
the
one
that
I'm
really
involved
with
on
a
day-to-day
basis
and
deploying
falco
is
not
easy.
C
Managing
falco
is
not
easy,
because
kubernetes
is
not
easy
and
orchestrating
applications
is
not
easy,
so
deploying
falco
means
that
you
need
to
essentially
to
push
this
kind
of
runtime
protection
on
your
whole
cluster
and
data
and
having
it
constantly
running
requires
a
a
decent
amount
of
expertise,
and
this
is
just
one
of
the
components.
So
each
of
the
components
like
histo
or
or
I
don't
know,
oppa
require
a
certain
certain
amount
of
skills
and
just
making
them
work
together
requires
a
non-negligible
amount
of
of
context.
C
From
this
point
of
view,
when
we're
talking
about
complexity,
typically,
one
metaphor
that
people
have
used
for
cloud
is
the
metaphor
of
pets
and
cattle
right
traditionally
before
the
cloud
before
virtualization.
Before
things,
like,
I
don't
know,
aws
we
used
to
treat
our
servers
as
pets.
Each
of
them
was
special
to
us.
C
Each
of
them
deserved
our
focus
and
our
care
each
of
them
we
needed
to
make
sure
it
was
healthy
and
that
it
was
happy
and
then
cloud
came
and
in
cloud.
Essentially
we
don't.
We
don't
worry
too
much
about
the
single
instance
anymore.
Typically,
we
have
many
of
them
behind
the
load
balancer
they
you
know
they
can
grow,
they
can
decrease
and
we
try
to
design
our
infrastructure
so
that
we
don't
care
about
the
single
one,
but
we
care
about
them.
C
As
a
group-
and
this
is
a
well-known
metaphor-
I
didn't
invent
it-
you
know
what
I
think
is
that
we
are
the
next
iteration
of
this
metaphor.
Now
we're
going
from
cattle
to
locusts.
Why?
Because
now,
our
entity
of
of
computing,
our
unit
for
our
applications
for
our
services
is
the
container
containers
are
small.
C
They
can
move
from
one
place
to
another,
pretty
fast,
because
there's
an
orchestrator
like
kubernetes
that
can
take
them
and
they
and
you
can
just
essentially
move
them
to
different
places
or
reorganize
them.
Based
on
the
workload
and
generate
a
quick
expansion
or
reduction
in
the
number
of
containers,
there's
many
of
them
it's
harder
to
keep
track
of
them.
C
They
not
only
cannot
be
approached
on
a
one
by
by
one
basis,
but
it's
almost
like
counter
productive
and
by
the
way,
if
you
are
not
careful
about
what
you
do
with
them,
they
can
be
very
dangerous
and
you
can
and
you
can
get
in
trouble.
So
welcome
to
the
era
of
locus
and,
of
course,
as
we
move
to
locust,
there
are
problems
that
we
have
to
solve
right,
it's
harder
to
understand
what
lockers
do
and
it's
definitely
potentially
harder
to
secure
them
again.
If
we
go
back
to
the
world
of
pets.
C
This
is
my
very
artistic
representation
of
the
classic.
You
know
like
multi-tier
application
right.
You
can
have
a
cache
in
front
of
a
web
server
that
then
talks
to
the
database
that
stores
the
state
right.
Nothing,
nothing
magic
here.
Nowadays,
the
same
architecture
looks
a
little
bit
more
like
something
like
what
we
have
in
this
slide.
Here
we
have
multiple
computing
nodes,
so
each
gray
box
here
in
this
slide
is,
is
not
typically
a
piece
of
physical
hardware
that
is
running
our
containers
or
a
virtual
machine
or
a
cloud
instance.
C
You
know
this
is
a
sort
of
it.
It
doesn't
really
matter
too
much,
and
then
we
have.
You
know,
containers
running.
On
top
of
these
nodes
and
for
simplicity,
I
put
four
containers
in
each
node
and
I
color
coded
them
in
based
on
the
service
they
belong
to.
You
know
before
we
had
like
the
database
server
and
the
web
server,
and
so
on
now
we
typically
have
services
deployments
that
sit.
C
You
know
behind
like
a
load,
balancer
or
dns
names,
and
they
are
implemented
by
multiple
containers
that
work
together
to
implement
those
services,
and
then,
of
course,
these
can
talk
to
each
other
in
arbitrary
ways.
So
it's
pretty
clear.
You
know
by
just
flipping
the
slides
and
compare
these
two
pictures
where
the
challenges
and
the
complexity
come
from
complexities
and
challenges
also
require
and
involve
approaching
these
with
a
new
mindset.
C
One
thing
that
is
pretty
clear
is
that
it's
not
only
a
matter
of
just
having
containers
and
doing
kubernetes
and
doing
orchestration
in
the
microservices,
but
the
whole
stack.
The
old
ecosystem
needs
to
evolve,
not
only
in
terms
of
new
functionality
like
in
the
slide
before
where
I
was
showing
the
new
projects
in
a
later
part
of
the
ecosystem.
But
each
of
these
projects
are
here.
C
You
know,
because
each
of
these
projects
are
a
way
of
re-thinking
re-imagining,
a
core
piece
of
functionality
that
was
implemented
in
a
certain
way
and
just
need
to
be
re-taught
with
a
blank
sheet
of
paper
when
you
go
from
this
model
to
this
model.
Otherwise
it
won't
work
segmentation,
like
your
traditional
firewall,
that
was,
you
know
you
were
putting
it
in
three
or
four
pieces
before
now.
You
need
to
just
think
about
how
you
do
it.
C
C
I
was
inspired
by
the
previous
generation
of
tools
like,
for
example,
snort
like
sc,
linux
and
so
on,
but
it
was
pretty
clear
that
it
was
impossible
to
apply
these
tools
in
a
natural
way
to
the
world
of
locusts,
and
that's
essentially
why
we
started
falco
and
that's
why
we're
working
on
it
and
we're
really
taking
a
different
approach
with
falco
containers
in
particular,
have
the
additional
challenge
that
they
tend
to
be
like
more
isolated,
which
is
great,
but
also
a
little
bit
more
opaque
and
challenging
in
terms
of
visibility
right.
So
not
only.
C
We
have
a
new
paradigm,
but
we
also
have
a
new
paradigm
that,
from
one
point
of
view,
provides
better
independence
and
isolation
and
structure
in
our
applications,
but
at
the
same
time
creates
challenges
in
terms
of
visibility
and
because
these
challenges,
very
often
people
say,
containers,
are
less
secure.
So
one
of
the
drawbacks
of
containers,
one
of
the
drawbacks
of
of
the
new
cloud
paradigm,
is
that
they
are
less
secure
than
our
previous
generation
of
applications.
C
It's
a
mat:
it's
a
matter
of
managing
the
complexity,
managing
the
different
pieces
and
components
that
I
was
mentioning
before
and
architecting
them
together
in
a
stack
that
covers
the
life
cycle,
in
particular
when
looking
at
the
security
for
kubernetes
security
for
cloud
native
and
security
for
containers.
I
like
to
approach
this
with
a
three-tier
approach:
build
run
and
respond.
C
Build
is
the
ci
cd
phase
of
building
and
creating
and
bringing
to
production
cloud
native
applications
and
building
means
essentially
going
from
the
code
the
editor
of
the
of
a
developer
that
creates,
you
know
the
components
of
an
application
to
essentially
bringing
that
application
to
the
production
stage
and
to
run
it
in
the
in
the
production
environment
during
build.
We
want
to
make
sure
that
early
on,
we
take
advantage
of
the
shift
left
in
security.
C
By
by
this.
The
application
then
goes
into
runtime,
and
here
essentially
it's
running
and
it's
runtime
is
the
place
where
the
application
delivers,
essentially
the
value
to
the
users.
But
it's
also
subject
to
attacks
from
the
external
world.
So
runtime
security
is
very
important.
Tools
like
falco
are
very
important
here,
to
essentially
being
able
to
detect
and
protect
applications
as
iran,
segmentation
and
micro
segmentation
is
very
important
in
this
phase.
C
This
is
a
one
of
the
areas
that
changes
the
most
with
containerization
and
with
kubernetes,
because
traditionally
you
know,
incident
response,
forensics
auditing
and
this
kind
of
stuff
was
done
by
instrumenting
and
adding
components
to
each
of
our
computing
units
like
when
right
when
the
unit
unit
was
was
a
is
the
host
or
the
virtual
machine.
You
have
a
full
operating
system
running
on
the
on
these
entities
and
if
something
happens
essentially
very
often
what
you
do.
Is
you
ssh
into
this
unit?
And
you
can
start
essentially
your
your
your
forensics.
C
C
C
B
Thank
you
lori,
so
yeah.
I
I
like
this
approach.
It's
essentially,
as
you
said,
it's
securing
end
to
end
the
life
cycle
of
the
application.
You
absolutely
have
to
look
at
every
single
step
of
the
life
cycle
of
this
application.
From
the
moment,
it's
thought
of
from
the
developers
all
the
way
to
going
to
the
it
operation
and
operationalizing
that
application
so
going
from
dev
to
production,
and
you
need
to
make
it
secure,
which
ties
us
back
to
what
our
theme,
which
is
dev
sec
ops.
B
We
need
to
have
all
those
three
components
working
together
and
in
your
environment
in
your
slide.
There's
one
thing
that
I
like
is
focusing
on
runtime,
because
guess
what
all
of
the
tools
that
you
mentioned,
whether
it's
your
ci
cd
pipeline,
your
your
registry,
your
alerting,
your
responding!
All
of
those
things
are
themselves
application.
B
All
of
them
have
their
own
life
cycle.
All
of
them
are
sitting
on
some
pieces
of
infrastructure
somewhere.
So
I'm
going
to
give
all
of
you
guys
that
are
attending
and
yourself
loris
as
well
the
benefit
of
the
doubt
and
say
that
you
know
all
of
that-
and
I
know
you
know
all
of
that
loris,
so
you've
probably
secured
all
of
your
application
very
well.
B
So
my
answer
is
the
locust.
I
love
that
analogy,
but
I
think
there's
one
element
on
this
earth
that
can
do
even
more
damage
and
that's
a
human.
So
I'm
I'm
really
sorry,
but
the
human
error
can
be
even
worse
than
any
swarm
of
locusts.
We
have
tons
of
examples,
I
mean,
if
you
open
any
of
the
websites
and
and
specialize
the
news
these
days
and
even
some
of
the
just
popular
news
media.
B
We
just
had
a
really
a
recent
example
today
with
a
ransomware
that
did
a
lot
of
damage
and
even
killed
someone
I
mean
we
don't
want
to
be
in
those
situations,
so
you
need
to
consider
the
whole
stack,
and
even
if
you
secure
your
application,
the
human
can
always
be
a
a
problem,
and
the
reason
being
most
of
you
know
that,
and
what
I'm
saying
is
is
probably
just
evidence
for
a
lot
of
you
guys,
but
it's
in
infrastructure
world.
In
most
enterprise
infrastructure
world,
there
is
still
a
lot
of
human
involved.
B
There's
still
a
lot
of
repetitive
tasks
and
what
happens?
We
all
know
that
as
apps
developers
as
devops
guys,
we've
learned
that
what
happens
when
you
have
a
lot
of
repetitive
tasks,
it
gets
boring
very
quickly
and
what
does
a
human
brain
do
when
it
gets
boring?
It
creates
errors,
it's
unwillingly,
making
errors
in
creating
and
in
doing
those
stack
those
tasks.
B
Do
you
can
you
make
your
platform
more
secure?
I
believe
you
can
and
you
can,
by
treating
essentially
your
infrastructure
more
or
less
like
you
would
treat
any
other
application.
So
I'm
just
stating
the
obvious
here,
many
of
you
most
of
you
probably
are
already
using
tools
like
chef,
but
that's
ansible.
B
Whatever
is
your
automation
tool
of
choice,
however,
that's
something
that
maybe
your
infrastructure
guys
are
using
for
your
apps,
but
not
for
everything.
Did
you
even
have
that
conversation
with
them?
Because
again,
if
your
infrastructure
is
not
secure
the
blast
radius
of
having,
for
example,
a
gaping
hole
in
your
virtualization
management
plane,
it
means
that
your
app
is
very
secure
in
your
vm,
but
the
bad
guy
already
is
seeing
all
of
your
vm,
including
yours.
So
there's
right.
There
is
the
problem.
There's
also
a
way
of.
B
As
loris
mentioned,
public
cloud
providers
have
evolved
a
lot
of
way
of
consuming
infrastructure
so
sometimes
falsely.
We
think
that
by
going
with
a
public
cloud
provider
with
aws
or
azure
or
gcp
or
whomever
we
are
secure
by
default,
no
you're,
not
all
those
guys
what
they
do
is
they
provide
you
infrastructure
at
your
own
risk.
It
doesn't
replace
and
it
doesn't
cover
any
of
the
risk
that
you're
taking
by
running
those
applications.
B
But
the
reality
is
as
much
as
I
would
love
to
say:
everybody
is
using
and
consuming
infrastructure
as
cloud
in
enterprise
world.
That's
far
from
being
the
reality
most
enterprises
out
there
are
still
using
traditional
storage,
networking
virtualization,
the
so-called
three-tier
infrastructure
stack
and
all
of
those
things
usually
are
silos
and
what
happened
if
one
of
those
silo
is
compromised,
then
the
whole
stack
is
compromised.
B
So
the
next
slide
talks
a
bit
about
the
security
through
the
cloud
native
throughout
your
cloud
native
journey.
One
element,
one
very
key
element
in
the
devsecops
trio-
is
the
security
team,
dev
and
ops.
Guys
these
days
we've
learned
to
try
and
work
together,
we've
patched
things
up,
sometimes
with
more
or
less
success,
but
we've-
and
I
I
come
from
the
itops.
I
have
10
years
in
that
industry
in
financial
sector.
B
So
it's
it's
something
that's
very
close
to
to
me
and
I
trained
as
a
developer,
and
so
I
was
doing
something
like
devops
for
years.
Even
before
that
train
came
in
and
so
for
me
it
was
a.
It
was
just
business
as
usual,
but
I
sort
of
opened
my
eyes
to
the
fact
that
that's
not
how
people
are
doing
it,
and
so
I'm
very
happy
to
see
that
dev
and
ops
have
now
starting
to
have
that
discussion
and
that
coherence
of
their
action.
B
I
realized
very
quickly
that
even
if
the
dev
and
ups
team
have
sort
of
bounded
together,
usually
they've
bonded
together
against
that
third
com,
that's
third
team-
and
if
you
dive
into
that,
why
is
that?
It's?
Because
they
don't
speak
the
same
language,
but
they
have
the
same
need
the
security
team.
If
you
just
listen
for
a
few
minutes
and
you
translate
their
concern,
you'll
see
that
they
are
very
very
close
to
what
we
call
now
this
devops
mentality.
B
So,
for
example,
the
security
team
will
come
with
this
question
of
I
want
auditability
and
loris
covered
that
very
well
in
the
dev,
the
world
of
devops,
like
with
containers
being
ephemeral.
How
do
you
audit
what's
happening?
So
you
need
those
tools,
you
need
those
those
accountability,
and
you
guys
already
have
that.
It's
just
a
matter
of
exposing
that
to
that
security
team.
They
don't
want
to
look
over
your
shoulder
to
everything
you
you
do,
but
they
have
their
own
accountability
of
those
things.
B
They
usually
want
to
see
automation
because
automation
means
it's
reproducible.
They
can
know
from
the
get-go.
What's
going
to
happen,
they
want
those
logs.
They
want
the
automation,
guess
what
your
tools
are
already
doing,
that
it's
just
you're,
not
using
the
same
language
as
the
security
team.
Next
thing
that
they
want,
they
want
simple
processes.
B
Why
remember
that
human
error
story,
if
you
have
complex
processes,
if
you
have
complexity
in
your
stack,
loris
explained
that
very
well
at
the
beginning
of
having
added
complexity
by
adding
a
lot
of
tools
that
require
a
lot
of
knowledge
specialized
knowledge
around
that.
That's
something
that
a
security
team
gets
scared
of,
because
then
there's
a
scarcity
of
skills,
there's
specialized
skills
that
may
or
may
not
be
there
when
you
need
it
to
audit
something
or
something
like
that.
B
So,
instead
of
those
things
by
having
micro
services,
something
that
we
know
in
the
devops
world
and
in
this
cloud
native
world
to
be
the
unit
of
computing
that
we
we
practice
a
micro
services
does
one
thing
and
one
thing
only
so
it's
very
simple
it's
as
simple
as
it
can
be
the
rest.
The
tools
around
it
are
automating
that
are
automating
those
process.
So
it's
not
human,
but
if
we
need
to,
we
can
go
and
look
at
what
this
process
is
doing.
B
The
third
pillar
of
security
team
is
they
want
no
description
and
what
I
mean
by
no
disruption
is
no
disruption
to
the
business.
They
are
accountable
for
the
business,
so,
if
there's
any
breach,
if
there's
any
downtime,
they
get
called
because
that's
their
responsibility.
They
they
are
the
first
responder
for
that.
In
many
cases
these
days,
and
so
by
having
non-disruptive
kubernetes
and
operating
system
upgrades
and
infrastructure
upgrades
by
having
a
real
modern
infrastructure
stack
that
you
can
treat
as
an
app.
B
It
means
that
you
can
provide
that
level
of
compliance
and
discussion
with
those
sec
teams
and
really
start
embedding
them
into
those
dev
sec.
Ops
trio,
the
next
part,
is
around
essentially
the
same
idea
of
security
through
the
cloud
native
journey.
If
you
start
bringing
together
those
ops,
those
dev
and
as
we
saw
those
security
practitioner,
if
you
start
bringing
all
of
those
people
together,
then
you
start
realizing
that
we
look
for
the
same
thing
and
we
are
just
talking
about
it
differently.
B
B
But
if
it
was
already
complex
to
secure
one
infrastructure,
think
about
all
those
things,
the
same
complexity
diagram
that
loris
was
showing
for
an
app
and
those
containers
interacting
between
compute
nodes.
You
start
to
have
the
same
thing
at
a
macro
level
between
clouds
between
cloud
providers
between
infrastructures
between
technologies
that
drive
your
infrastructure,
so
you're,
adding
a
lot
of
complexity
even
before
you
start
starting
the
first
app
and
so
what?
If,
instead
of
having
those
layers
upon
layers
upon
layers
of
complexity,
what
if
your
infrastructure
was
an
app
like
any
other?
B
A
C
C
But
it's
almost
a
bi-dimensional
chart
here
right
because
it's
right
to
left,
but
it's
also
up
and
down
in
our
stack
right,
because
each
of
the
components
that
are
in
the
left
to
right
then
are
based
on
a
stack.
That
is,
as
you
were
saying
here,
you
know,
can
can
be,
on-prem
can
be
in
the
cloud,
but
more
often
is
in.
It
is
and
will
be
more
and
more
in
a
combination
of
different
multiple
places.
C
B
C
C
Yeah,
I
will
let
you
you
know,
answer
that
just
clearly.
These
is
a
trend
that
I
see
more
and
more
just
the
approach
of
cloud
vendors
of
starting
essentially
offering
or
google
anthony's.
You
know
all
of
these
start
start
offering
essentially
a
consistent
or
trying
to
offer
a
consistent
experience
from
that
stands
from
the
traditional
cloud
and
goes
boring
to
the
the
data
center.
This
is
a
like
definitely
a
business
kind
of
of
of
trend
for
the
cloud
providers.
C
Competition
in
the
data
center
becomes
a
very
important
factor
in
the
competition,
so
business-wise.
This
makes
sense,
but
I
feel
like
at
least
conceptually.
It
makes
sense,
also
architecture-wise,
because
bringing
consistency
definitely
allows
to
create
better
infrastructures
and
from
the
security
point
of
view,
which
is
the
angle
we
come
from.
Definitely
consistency
helps
security
right
now.
The
question
is
I:
I
find
the
two
trend,
two
trends
that
are
a
little
bit
competing.
C
B
B
That
kind
of
of
aspect
are
too
often
ignored
by
developers
and
more
of
a
consideration
or
preoccupation
from
the
security
guys,
who
have
often
times
their
who
would
sorry
from
whom
this
is
the
the
job
to
to
make
sure
they're
abiding
by
all
those
laws,
and
so
to
get
back
to
the
question
of
security
of
cloud
infrastructure
moving
toward
on-prem.
I
believe
one
aspect
outside
of
the
obvious
business
angle
that
you
mentioned
is
this
notion
of
sovereignty
of
data
of
where
is
my
data?
Where
is
my
app?
B
Who
has
access
to
it?
What
can
those
person
do
with
it?
And
again,
it
goes
to
not
only
the
human
error,
but
the
human
oversight
of
who
has
access
to
those
data,
and
so
I
don't
know
if
you're
in
switzerland,
for
example,
you
may
not
want
your
data
to
be
accessible
by
someone
else.
You
may
want
to
be
the
switzerland
of
data.
It
might
be
your
new
way
of
story.
After
storing
money
in
banks,
you
may
want
to
store
data
in
data
vaults
and
have
sovereignty
over
that.
B
B
And
now
we
see
this,
the
cycle
starts
expanding
again.
We
are
seeing
the
trend
of
those
compute
going
back
out
because,
for
example,
in
the
list
of
use
cases
that
you
mentioned
at
the
very
beginning
for
it
for
iot
for
ai,
you
don't
necessarily
want
or
have
the
luxury
of
going
all
the
way
to
a
cloud
so
having
those
the
way
of
consuming
a
cloud
very
locally
and
having
a
cloud-like
feeling
of
an
experience.
A
A
C
B
B
So
when
you're
talking
about,
for
example,
just
moving
data
is
already
a
challenge,
you
need
a
tool
that
you're
going
to
be
able
to
convert
from,
let's
say
ami
to
whatever,
to
whatever
storage
your
destination
infrastructure
use
so,
for
example,
vmdk
or
whatever.
So
you
need
already
there's
some
complexity
in
that
whatever
you
choose,
you
need
to
make
it
an
automated
tool.
B
So
if
the
tool
doesn't
provide
that
automation
because
we
are
devops
and
because
we
are
now
taking
a
devops
approach
to
infrastructure
and,
as
I
said,
we're
considering
infrastructure
as
an
app
like
any
other,
all
those
tools
that
we
use
that
provide
those
kind
of
security,
I
mean
shameless
plug
for
nutanix,
on
that
we
have
a
tool
called
move.
Who
does
just
that?
B
So
we
have,
for
example,
that
that
capability
we
have
orchestrated
that,
but
we
do
it
in
a
way
where
every
single
action
that
is
taken
from
cloning,
a
disk
to
converting
it
to
powering
down
the
machine
or
everything
that
everything
is
audited.
So
you
get
a
trace
of
every
single
action
who
does
what
at
what
time
and
every
single
action
that
has
been
taken?
B
It's
still
a
an
area,
that's
very
lacking
in
terms
of
automated
tools
for
a
lot
of
those
actions
and
there's
still
a
lot
of
development
and
a
lot
of
movement
in
that
area,
not
necessarily
as
much
as
I
wish.
There
would
be,
because
I
see
the
developer
sides
of
the
house
getting
all
the
new
shiny
toys
and
they
get
all
that
automation,
but
the
infrared
guys
are
left
wanting,
and
so
there
is
opportunities
for
that.
So
companies
like
myself
with
nutanix.
C
No,
I
just
I
just
I
agree
with
you.
I
just
want
to
add
a
thought
that
might
seem
trivial,
but
it's
not
completely
trivial,
which
is,
if
you
want
to
be
multi-cloud
and,
at
the
same
time,
have
good
consistency
for
security
use
kubernetes
and
you
use
kubernetes.
If
you
remember,
let
me
share
this
light
right
with
the
tools
in
this
slide.
The
stack
we
were
talking
about,
the
the
in
my
part
of
the
presentation.
C
C
C
So
the
beauty
of
the
kubernetes
tech
and
the
reason
why
I
very
often
con
use
operating
system
of
the
cloud
to
this
to
describe
kubernetes
is
that
it's
an
opinionated
way
to
run
your
applications
in
a
way
that
you
can
do
in
your
data
center.
You
can
do
it
completely
by
yourself
or
you
can
do
with
different
degrees
of
essentially
support
from
the
cloud
provider.
So,
instead
of
mentioning
you
know
something
specific
or
or
or
specific,
you
know
like
approaches
or
your
use
cases
or
vendors.