►
From YouTube: Panel: Whither Security in a Cloud-Native World?
Description
Moderated by Christopher Lijenstople, Tigera
Panelist:
Michael Ansel, Box
Joseph Jacks, Apprenda
Traditionally, the security team has been the "immovable object" within any enterprise: any new project must be meet a rigid set of security rules in order to proceed. Into that established world order, an "irresistible force" is emerging with increasing momentum: the cloud-native approach redefines how applications are architected, throwing many traditional assumptions out of the window. The two are on collision course. What will be the fall-out? This panel will discuss what the world looks like after that collision: How will applications be secured? Who will define security policies? And how will they be enforced across hybrid environments - both private and public clouds, and traditional bare metal / VM and cloud-native, containerized workloads?
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
We
do
want
the
panel
to
be
fairly
interactive,
so
we're
going
to
talk
a
little
bit
beginning
about
our
views,
but
then
we
really
want
this
to
be
an
interactive
set
of
questions.
If
we
don't
get
any
questions,
well,
I'll
explain
what
we're
going
to
do
in
a
minute,
but
so
please
feel
free
to
to
to
ask
questions
of
the
panel
as
we
go
so
like
to
introduce
the
other
panel
members.
A
First
of
all,
JJ
JJ
is
the
founder
of
his
matic
and
now
been
bought
by
aprenda
and
he's
done
a
lot
of
product
and
management
work
at
aprenda
and
an
Mesa
sphere
and
tibco,
and
you
know,
founded
the
cube
con,
which
is
now
part
of
the
CNC
F
family
as
well.
He
also
as
a
as
a
side
trained
as
a
classical
guitarist
for
how
many
years
now,
how
many
years.
A
12
13
years,
so
if
there
are
no
questions,
we're
going
to
get
an
air
guitar,
classical
guitar
conference
from
JJ,
so
I
suggest
you
ask
questions
because
he
don't
have
the
guitar
for
him.
My
cancel
is
also
joining
us
from
box
mics
and
I.
Sorry
at
box
mainly
focused
around
infrastructure
and
enabling
developers
to
to
launch
their
applications
in
a
seamless
way
within
boxes
infrastructure
and
before
that
had
done
work
at
netapp.
So
he
was
on
the
dark
side
and
is
now
on
the
light
side
as
a
actual
operator.
A
Building
things
using
containers
and
the
kind
of
infrastructures
were
talking
about
so
I
think
we're
really
lucky
to
have
him
on
the
panel
as
well,
and
I'm
chris
roling
sophie
I'm
the
founder
and
CTO
of
thai
gara
and
we're
the
home
of
a
project
called
Project
calico,
which
is
networking
in
policy
for
container
environments
and
cloud
native
environments.
So
with
that,
you
know
why
we
go
ahead
seat
and
so
I
guess
the
first
one
think
I'll
just
ask
I,
guess
start
with
JJ.
A
You
know
what
do
you
think
the
challenges
are
as
we
a
what
if
the
classical
challenge
has
been
around
developers
and
security,
especially
relates
to
networks,
but
in
general,
and
how
are
those
challenges
changing
as
it
relates
to
containers
as
people
start
deploying
more
of
a
container
type
environment?
What
you're,
seeing
with
aprenda
sure.
B
You
then
have
to
sort
of
think
about
how
you
handle
authentication
authorization
into
different
services.
How
your
application
sort
of
you
know
behaves
in
terms
of
connecting
two
different
services
that
it
might
depend
on
or
other
other
things
in
a
distributed
environment
and
it's
becoming
I
think
more
and
more
important
for
for
developers
to
actually
solve
these
problems.
I
think
that's
why
we've
seen
a
big
explosion
of
tooling
and
different
different
options
for
people
to
try
and
solve
these
problems.
B
So
it's
interesting
I
think
if
you
talk
to
like
the
big
huge
enterprise
companies,
there's
a
perspective
there
around.
You
know
lots
of
contention
between
Network
teams
and
security
teams,
as
it
relates
to
application
development,
because
there's
there's
there's
lots
of
challenges
with
how
you
know
application
developers
want
to
own
a
lot
of
the
security
bits
actually
control
things
there,
which
is
sort
of
encroaching
and
kind
of
stepping
on.
You
know
the
territory
or
the
domain
of
these
sort
of
their
specialized
skilled
areas.
B
You
know
we,
you
know
we
focus
on
like
very
large
enterprise
customers,
so
we
have
a
lot
of
interesting
data
and
perspectives
from
those
companies
kind
of
going
through
this
dynamic
of
the
big
silos
trying
to
learn
about
the
new
technologies
and
how
to
how
to
collaborate
with
you
know
the
the
sort
of
the
full
stack
or
that
sort
of
end-to-end
lifecycle
teams-
and
you
know
I
think
it's
it's.
It's
really
interesting
to
see
a
lot
of
these
things
kind
of
come
together
and
we're
gonna
start
to
see
a
lot
of
evolution.
B
I
think
lots
of
lots
of
terms
around
you
know
how
how
operators
are
you
know
their
roles
are
sort
of
needed
to
get
redefined
in
many
different
ways.
I
think
that's
I,
think
that's
really
true.
You
know,
there's
there's,
there's
different
different
perspectives
there,
but
I
think
you
know
with
security.
All
of
the
all
of
the
preconceived
notions
of
security
are
getting
flipped
on
their
on
their
head.
I
think
because
of
the
the
form
factor
of
how
you
packaged
applications
changing,
but
but
also
I,
think
because
of
the
Internet.
B
Really,
you
know
applications
traditionally,
you
know
most
of
them
ran
from
from
the
beginning
of
enterprise
software
development,
to
say
the
last
10
years,
like
behind
the
firewall
or
in
private
infrastructure
environments
and
the
the
security
profiles
attack
surface
areas.
All
these
things
were
radically
different.
Over
the
last
decade,
we've
seen
the
internet
just
explode
and
growth
and
the
number
of
people
actually
on
the
internet
and
the
applications
that
are
getting
develop
now
I
think
actually
mere
some
of
the
qualities
of
the
internet,
which
is
you
know,
they're
distributed
their
fault
tolerant
there.
B
C
Absolutely
so
a
little
bit
of
context.
If
you
haven't
heard
of
box,
we
do
cloud
storage
for
a
lot
of
large
companies,
so
like
GE,
IBM
federal
government
stuff,
like
that,
so
security
is
very
much.
Our
bread
and
butter
dealing
with
large-scale
systems
is
very
much
our
bread
and
butter
over
the
course
of
the
last
10
year
at
bux
turns
11
this
year.
So
over
the
course
of
the
last
11
years,
we've
built
up
a
pretty
sizable
physical
hardware
infrastructure.
C
We've
got
three
data
centers
that
we
run
our
app
out
of
with
thousands
of
servers
so
dealing
with,
and
we
very
much
been
in
the
more
traditional
world
of
managing
physical
servers
dealing
with
separated
development
operations
and
security
teams
having
a
lot
of
the
expectations
and
requirements
coming
from
our
customers,
we've
ended
up
with
a
more
enterprise
model,
but
the
same
time
were
small
enough
that
we
can
be
flexible
and
start
looking
at
ok.
This
is
the
way
that
these
large
enterprise
companies
have
traditionally
solved
these
problems.
C
How
can
we
continue
to
level
up
our
infrastructure
and
not
be
not
be
kind
of
stuck
in
that
in
that
more
traditional
world
where,
when
you
need
a
new
server
or
you
need
a
new
akal
pushed
or
something
like
that,
you
have
to
spend
six
to
eight
weeks
waiting
for
someone
else
to
go
through
and
do
all
of
the
work.
For
you
get
a
new
server
loaded
in
the
datacenter.
A
C
A
So
you
know
at
at
thi
guerra
we
we've
been
a
response
or
of
an
open
source
package
called
Project
calico,
which
does
networking
in
policy
for
for
cloud
native
environments
and
I
think
our
experience
has
been
talking
to
a
number
of
enterprises
mirrors.
But
what
we've
heard
a
lot
just
said
here
and
that
a
lot
of
folks
are
starting
down
this
road
and
where
most
enterprises
have
started
down
this
road
as
they
move
to
a
more
cloud
native
environment?
Is
they
start
off
with
our
security
guys
or
this
this
special
little
bucket?
A
How
many
people
here
do
security
or
the
security
guys
with
the
yeah
you're?
Putting
that
wonderful
little
bucket
of
you
know
by
the
way,
excellent.
You
know
you
got
the
paranoid
bit
set,
but
they're
they're
treated
as
it's
this
special
discipline
and
it's
you
know
that
they
have
their
own
rules
and-
and
you
know
we're
going
to
just
sort
of
initially
what
most
enterprises
will
do
is
say,
we're
just
going
to
do
this
cloud
native
migration,
this
container
migration
and
we're
going
to
leave
the
security
guys
in
the
security
infrastructure
and
go
lesser
extent.
A
A
A
You
know,
as
as
Michael
was
just
saying
you
know,
I
the
developers
want
to
push
a
diff
and
just
have
it
flow
right
through
so
I
want
to
be
able
to
push
an
update
in
five
minutes
or
30
seconds
or
or
whatever
it
is,
and
I
may
want
to
do
that.
Multiple
today
so
now
these
containers,
which
generally
are
immutable,
you're,
not
changing
a
container
you're.
You
know
standing
up
a
new
one,
killing
the
old
one.
It
gets
a
new
address.
A
It
may
be
in
an
entirely
different
address
range,
depending
on
how
it
got
stood
up
so
now,
I'm
having
orders
of
magnitude
more
churn
in
my
infrastructure,
but
the
back
end
that
that
networking
and
and
to
a
larger
extent,
the
the
security
control
component
is
still
based
very
often
around
that
ticket
driven
environment.
So
we
now
have
a
huge
impedance
mismatch
between
the
speed
at
which
the
developers
believe
they
need
to
go
to
push
apps
and
what
the
infrastructure
is
capable
of
supporting
so
the
things
that
were
causing
conflict
in
the
vm
days.
A
A
We've
got
some
questions,
but
also
I
get
questions
from
the
floor
or
comments
from
the
floor
we
can
discuss,
but
that
sort
of
the
what
we
wanted
to
talk
about
today
was
you
know
what
are
the?
What
are
people
seeing
out
there?
What
are
some
of
the
things
to
think
about?
As
you
start
thinking
about
securing
these
environments
and
we're
a
folks
a
little
bit
on
network
security,
but
we
don't
need
to
bind
it
specifically
to
that.
A
You
know
what
is
the
challenge
and
what
are
some
people
thinking
about
in
order
some
of
the
ways
you
might
want
to
think
about
this.
So
before
we
go
into
some
of
the
questions
we
have
here,
questions
any
questions,
comments
from
the
audience
you
know
are:
we
are
we
outlining
a
real
issue
that
people
out
there
are
seeing?
Are
we
making
this
up
and
we're
just
envisioning
this
in
our
head?
You
know:
is
there
anyone
here
who
wants
to
take
a
shot?
There's.
A
Okay,
well,
why
we
kick
things
off
anyway,
with
I
guess,
a
first
question,
so
how
many
people
have
started,
deploying
I,
guess
what
you
can
classically
call
cloud
native
infrastructure
I
know
in
the
keynotes
they
start
talking
about.
Many
people
are
just
taking
legacy,
workloads
and
container
izing
them,
but
you
know
at
least
has
to
start
down
that
road.
What
percentage
of
folks
have
actually
started?
Deploying
these
kind
of
technologies
versus
thinking
about
them
deploying
show
of
hands?
That's
some
percent.
Looking
at
it
ended
up
in
the
wrong
room.
A
A
You
know
you're
not
going
to
move
all
your
applications
at
once,
you're
still
going
to
have
legacy
database
servers
and
other
things
out
there
that
your
new
environment
is
going
to
need
to
talk
to
and
you're
going
to
have
bits
of
your
infrastructure
that
our
legacy.
You
know
your
your
finance
guys
aren't
gonna,
be
particularly
happy
with
you.
Deprecating
kit,
you
just
bought
two
years
ago
because
there's
ass
brand
new
thing
out
there.
So
there's
always
this
interface
between
legacy
or
existing
environments
and
new
environments,
both
the
applications
and
the
infrastructure
itself.
A
C
So
absolutely
this
is
definitely
something
we've
run
into
and
been
actively
working
on.
Continuing
to
solve,
as
I
mentioned
box,
has
a
kind
of
your
traditional
data
center
infrastructure
architecture,
we're
managing
all
physical
servers.
We've
got
everything,
split
layer,
three
doing
routing
and
ackles
for
all
of
our
security
between
different
segments
of
our
application
and
that
works
really
well.
C
It
works.
It
works
very
well
and
it
scales
great
as
long
as
you
only
put
one
I
paper
box,
the
moment
you
start
doing,
virtualization
or
containerisation,
you
suddenly
start
increasing
the
density
rapidly
with
how
many
IPS
you've
got
per
box.
So,
whereas
before
we
were
planning
on
we're,
only
going
to
have
40
servers
and
maybe
a
couple
of
double
IPS
so
give
each
rack
64
IPS,
we
can
now
put
64
IPS
on
a
single
box
and
the
rest
of
the
rack
has
now
kind
of
screwed.
C
So
we've
definitely
run
into
that
and
that
this
wasn't
intended
to
be
a,
but
that
that's
where
it
lets
something
like
calico
has
really
come
in,
because
we
can
so
that
there,
something
like
that,
has
shown
up
for
us
as
a
way
to
start
specifying
our
rules
at
a
much
more
granular
level.
The
way
that
developers
tend
to
think
about
work
is
in
terms
of
I,
have
this
service
and
I
needed
to
talk
to
this
other
service
and
I
need
this
third
service
to
be
able
to
talk
to
me.
C
They
don't
usually
think
in
terms
of
physical
servers,
even
for
a
company
that
has
been
physical
servers
for
our
entire
life.
Our
developers
still
want
to
think
about
things
in
terms
of
their
service
and
not
in
terms
of
their
servers
so
being
able
to
kind
of
change
that
policy
model
around
and
specify
this
service
can
talk
to
this
service
and
then
having
underlying
infrastructure
that
can
support
that
has
been
critical,
doing.
I!
Guess
that
you,
you
could
try
to
implement
this
in
a
another
way
like
doing
this
directly
on
the
switches.
C
The
way
that's
been
historically
done,
but
you
tend
to
blow
out
the
cam
tables
inside
inside
the
switches
which
is
the
echo
matching
stuff,
there's
a
finite
size
for
how
many
apples
you
can
put
on
a
switch
and
if
you
start
setting
up
a
path
for
this
server
can
talk
to
the
server
the
server
conducted
this
server.
This
server
can
talk
to
this
server.
When
you
have
several
thousand
servers,
you
blow
out
that
table
almost
feel
silly
yeah.
So
that's
been
an
adventure
for
us.
C
A
The
one
thing
we're
going
to
JJ
on
that
for
those
of
you
who,
how
many
people
run
infrastructure
here,
how
many
of
you
have
shall
we
call
them
legacy
rules
in
your
infrastructure
in
your
firewalls
that
you
don't
know
why
they're
there
anymore,
how
many
of
you
ever
tried
to
remove
those
and
discover
that
removing
rules
that
you're
not
quite
sure
if
they're,
necessary
or
not,
will
usually
educate
you
that
they
may
be
this?
This
sort
of
leads
to
firewall
rules
and
middle
boxes.
In
my
experience,
so
I
have
some
operational
experience
as
well.
A
B
I
mean
I
think
it's
it's
just
going
back
to
how
people
are
now
forced
to
sort
of
think
through
how
distributed
systems
communicate
and
before
you
know,
we
have
very
static,
static
assignment
of
networks
of
storage
and
compute
and
applications
tied
to
hosts.
Where
you
know
you
were
doing
port
management
with
a
single
IP
per
machine,
and
you
had
various
systems
that
helped
to
help
do
that
at
the
switch
level.
B
And
now
this
witness
switch
itself
instead
of
just
being
top
of
rack,
is
now
sort
of
getting
disaggregated
across
across
the
entire
data
center
and
across
all
the
different
compute
units,
and
so
routing
and
all
these
things
become
become
super
complex.
So
I
just
think
it's
it's.
It's
really
interesting
to
see
lots
of
different
tools
out
of
this,
because
it's
sort
of
born
out
of
necessity.
But
you
know
what
I
spend
a
ton
of
time
on
is
Cooper
Nettie's
and
Cooper.
B
You
know
your
services,
you
know
you,
you
actually
provide
a
unique
routable,
IP,
/,
/,
sort
of
application
construct,
whatever
that
happens
to
be,
and
that
allows
for
much
much
more
flexible
and
scalable
communication
abstractions
between
your
between
your
services
and
that
happens
to
be
in
Cooper
Nettie's
at
the
layer
2
level.
So
you
have
to
do
lots
of
things
to
get
services
to
communicate
more
more
efficiently
and,
and
you
know
lock
down
communication
at
layer,
3
and
4
and
above
and
that's
where
things
like
calico
come
in.
I
think
you
know
calico
and
cooper.
B
All
not
at
all
I
mean
what
we're
seeing
with
customers.
Is.
You
know
as
you?
It's
not
just
Cooper
Nettie's
either
it's
it's
it's
the
sort
of
the
suite
of
options
that
are
coming
out
there,
just
really
amazing
representations
of
these
ways
of
thinking.
As
you
start
to
develop,
you
know
using
distributive
distributed
systems,
whether
it's
mezzo
source
warm
or
these
other
services.
Like
you
need
you
need
to
rethink
the
security
architecture
of
your.
You
know
of
your
entire
of
your
entire
application
portfolio.
B
I
mean
what
we're
seeing
on
the
on
the
sort
of
traditional
quote-unquote
legacy:
enterprise
side
companies
like
Boeing
and
and
McKesson,
and
JP
Morgan,
JP,
Morgan,
bank
and
others.
Is
there
there's
billions
of
dollars
in
investment
in
the
core
infrastructure
that
supports
live
transactional
systems
running
you
know
all
the
mission-critical
apps
and
you
know,
unsurprisingly,
those
companies
aren't
going
to
throw
all
that
away.
B
You
know
how
can
we
introduce
containers
and
cluster
management
systems
into
you
know
into
the
enterprise
network
into
the
enterprise
security
posture
and
all
these
other
things.
So
I
think
I
think
that's
that's
really
where
we're
gonna
start
to
see
a
lot
of
focus
and
a
lot
of
innovation
over
the
next
six
months,
nine
months,
18
months
and
it's
gonna
be
really
interesting
to
see
what
happens.
D
Hi
Jon
Belmar
from
info
Bloxham
I,
something
Michael,
said,
really
struck
home
with
me,
because
we've
been
looking
at
this
a
lot
too
and
that's
it.
You
know
you
really
want
to
define
these
policies
in
terms
of
service
and
you
can
talk
to
service
be,
and
it
would
seem
that
in
order
to
do
that
and
what
we've
been
looking
at,
is
you
really
need
to
you?
Need
you
need
two
more
things.
You
need
this
service
registry?
D
That's
going
to
have
the
information
about
which
containers
map
to
which
services,
and
then
you
need
some
sort
of
repository
for
the
policy
and
I
guess
something
to
bring
them
together
and
enforce
the
policy
somewhere.
So
what
are
you
seeing
out
there
in
terms
of
those
different
components
and
and
what's
being
built
in
the
industry
right
now?
It's.
A
The
conversation
so
I
think
the
work
that
Cooper
Nettie's
specifically
has
done
around
both
labeling
metadata
and
the
policy
frameworks.
Okay,
kuber
Nettie's
is
introduced
for
networking
anyway,
a
policy
API
which
is
now
in
beta
and
v1
3
and
v1
dot.
4,
it's
going
to
be
GA
that
allows
you
to
basically
attach
a
policy
to
a
an
arbitrary
number
of
pods
and
that's
done
by
a
selector
algorithm.
So
basically,
KU
bearnaise
allows
you
to
label
like
many
orchestration
systems,
allows
you
to
label
a
container
put
whatever
tags
metadata.
A
This
policy
will
allow
inbound
traffic
from
things
labeled
a
on
port
1534,
so
this
starts
becoming
a
way
between
the
use
of
labeling
and
policies
that
are
selected
by
those
labels
becomes
a
very
flexible
way
of
managing
exactly
what
you're
talking
about
it's
a
conversation.
I'm
seeing
happening
elsewhere,
but
I
would
say
that
definitely
the
in
my
opinion,
a
way
that
the
KU
bearnaise
community
is
probably
a
little
bit
further
ahead
in
this
regard
than
some
of
the
other
systems.
C
Now
that
does
was
gonna
point
out
is
from
an
API
perspective
and
many
other
perspectives
as
well,
but
particularly
from
an
API
perspective.
Kuber
Nettie's
is
absolutely
beautiful
in
this
aspect
being
able
to
specify
all
of
your
instances,
your
containers
have
them
all
roll
up
through
a
single
API
that
allows
you
to
select
all
of
those
match
policy
to
that
and
have
the
equipment
of
the
most
beautiful
join
query
you've
ever
seen.
It
really
is
nice
that
you
can
can
just
kind
of
throw
all
this
out
there
and
say
all
right
now.
C
B
A
B
B
The
great
thing
is,
you
can
assign
these
key
value
pair
labels
and
those
things
can
be
completely
arbitrary
or
whatever
they're,
whatever
their
intended
to
be,
whether
it's
for
a
user
for
a
service
or
for
an
environment,
and
you
select
and
you
query,
against
those
those
objects,
and
it's
it's
a
really
beautiful
design.
I
think
it's
one
of
them,
one
of
the
more
powerful
aspects
of
the
system.
B
A
A
If,
if
they've
been
thinking
through
this
answer,
what
they've
just
realized
is
that
now
the
developer,
which
is
normally
the
person
in
Coober
Nettie's,
who
creates
the
metadata
that
goes
into
the
pods
back,
is
the
one
deciding
what
policies
are
going
to
be
applied
by
what
labels
they
put
in
and
what
things
go
into
the
policy
API.
So
there's
going
to
be
some
people
where
that
is,
you
know
who
my
developer
gets
to
decide?
Who
can
you
know
who
this
thing
can
talk
to
you?
A
B
Yeah,
that's
a
really
interesting
question.
I
mean,
I
think
you
know
coo
coo
pernetti's
is
very
popular
with
developers
specifically
for
a
few
reasons,
I
think,
because
it's
got
amazing
api's
and
you
know
very,
very
well-defined
primitives
that
have
sort
of
narrow
scope
and
developers
sort
of
like
like
like
to
understand
things
to
their
component
parts
and
then
reasoning
up
from
there.
So
I
think
in
that,
in
that
regard,
Cooper
Nettie's
has
a
lot
of
people
using
it
from
a
development
perspective
and
when
they
start
to
understand
and
appreciate
the
power
of
these
primitives.
B
You
know
it's
a
it's
a
it's
a
full
distributed
system
for
managing
your
your
data
center,
your
all
your
applications
in
the
data
center.
Obviously
you
know
developers
who
commits
to
start
it's
assuming
roles
that
previously
were
very
specialized,
whether
their
security
area,
whether
they're
for
infrastructure,
operation
management
or
for
networking
and
all
these
things
and
I
think
that's
actually
a
really
great
thing.
It's
because
the
future
is
all
about
distributed
systems.
If
people
have
general
understanding
of
how
distributed
systems
work
in
the
context
that
exists
in
large
environments
and
data
center
environments.
B
That's
that's
just
going
to
be
a
net
positive
for
everyone.
I
think
the
way
Brendan
Burns
describes
this.
Who
is
the
co-creator
Cooper
Nettie's?
Is
you
know?
Cooper
nyse's
exists
to
sort
of
make
distributed
systems
a
cs101
exercise
which
I
think
is
really
cool
now
on
the
side
of
like
at
you
know,
should
developers
actually
be
the
ones
defining
what
talks
to
what
like
I?
Think.
That's
a
really
big
question,
probably
over
time.
B
So
I
think
all
these
new
systems,
all
these
new
cloud
native
paradigms,
are
forcing
people
to
become
more
knowledgeable
about
all
the
different
aspects
of
development
and
operations,
which
is
which
is
really
great
but
I.
Think,
as
the
question
is,
is
it's
sort
of
poking
at
you
know?
They're
they're
definitely
need
to
be
lines
drawn
in
many
areas,
so
I
think
that's
kind
of
my
take
on.
C
Yep
so
as
as
JJ
mentioned
in
enterprise
companies,
where
you're
dealing
with
all
those
compliance
things,
you
have
a
lot
of
rules
and
regulations.
You
have
to
follow.
We
get
to
deal
with
every
single
one
of
them,
pci
FINRA
for
FedRAMP,
HIPAA,
well
and
I-
think
that's
all
of
them,
but
basically
we
get
to
deal
with
all
of
those
fun
things
of
how
do
you?
C
How
do
you
meet
all
of
the
check
boxes
that
are
there
and
and
also
have
a
secure
environment,
because
compliance
doesn't
necessarily
mean
secure,
but
so
how
do
we
do
all
of
those
different
things
and
a
lot
of
what
it
turns
into
particularly
for
us
is
finding
figuring
out
what
this,
what
our
security
folks
really
care
about?
They
spend
a
lot
of
time.
C
So,
within
this
space,
these
are
the
types
of
things
you
need
to
think
about,
and
they
can
communicate
that
back
to
the
development
teams,
and
then
the
development
teams
can
start
working
within
those
working
within
that
realm
understanding
when
when
they
want
to
break
out
of
that
and
and
kind
of,
that's
that's
the
point
where
they
turn
on
and
go
back
to
the
security
team
and
say
alright.
We
we
need
to.
C
We
need
to
do
something,
that's
different,
something
that's
not
normal
here
now,
if
you
just
it
on
some
level,
you
want
to
trust
your
development
team
to
do
the
right
thing.
Trust
is
an
important
part
of
a
company's
growth
and
and
really
being
able
to
move
fast.
At
the
same
time,
you
don't
want
to
rely
purely
on
trust,
because
security
based
purely
on
trust,
would
be
no
passwords
anywhere,
which
is
which
is
not
necessarily
true.
So
what
you
can
set
up
with
with
policies
in
communities.
C
You
can
start
layering
those
policies
together
and
say:
here's
here's
a
base
policy.
This
says
that
this
is
what
production
is.
This
is
what
the
dev
environment
is
and
say.
The
traffic
shall
not
pass
between
those
two
things,
but
within
production
a
developer
can
control
anything.
They
want
and
say.
Alright,
this
service
can
talk
to
this
other
stories
in
production,
but
we've
kind
of
put
that
hard
wall
between
dev
and
prod
or
even
tighter
ranges.
C
So
we
could
say:
we've
got
the
front
end
zone
and
we've
got
the
back
end
zone
with
in
production
and
we're
going
to
draw
a
wall
between
those
and
say
only
specific
traffic
can
go
through
here.
That
has
been
reviewed
by
people
who
are
very
good
at
understanding
threat
models,
but
within
those
zones
we
still
want
access
control,
but
we
can
trust
the
development
team
to
come
up
with
the
right
access
controls
to
go
between
different
components
in
that
system
and.
A
D
A
You
know
the
the
dragon
comes
up
medieval,
knight
and
says
hard
crunchy
outside
soft
chewy
inside
you
know,
once
you
get
through
that
perimeter,
I
can
go
anywhere
and
the
problem
in
a
in
a
containerized
environment
where
have
a
huge
number
of
very
dynamic
containers
is
once
I
can
subvert
or
somebody
deploys
buggy
code
that
runs
wild
and
does
a
ddos
unintentional
d
das.
It's
not
always
this
trust,
and
sometimes
people
write
buggy
code.
A
The
attack
surface
is
infinite
within
that
within
that
perimeter,
I
can
talk
to
anything,
so
I
can
now
hop
from
different
things.
So
I
find
the
bit
of
information
I
want,
or
the
ddos
takes
me
down
the
idea
that
we
can
start
doing
this
with
some
of
these
models
to
say
even
within
the
front
end
zone
fronted
load
balancers
should
only
be
if
they're
doing
say,
authentication
should
only
be
able
to
send
ldap
traffic
to
this
set
of
ldap
servers
or
LDAP
proxies,
which
are
going
to
do
the
the
off
for
you.
A
No
one
else
should
be
talking
ldap,
so
I
can
start
constraining
the
attack
surface
by
the
developers.
You
know
it's
microservices,
unlike
VMS,
where
people
didn't
know
you
know
big
monolithic,
vm
lose
it
need
talk
to
I,
don't
know
in
this
case,
when
I've
got
these
small
micro
serviced,
containers
I
know
exactly
what
this
singing
sucked
it's
a
front-end
load
balancer
needs
talk.
A
So
that's
what
another
case
on
the
tiering
that
I've
seen
talking
to
one
large
corporate
was
their
security,
guys
that
something
interesting
since
I
don't
care
if
a
workload
is
labeled,
PCI
is
or
not
pci-x.
If
it's
labeled
PCI
it's
going
to
be
in
the
PCI
walled
garden
and
it
can't
exfiltrate
data
anywhere.
If
it's
labeled,
not
PCI,
then
it
sits
outside
the
walled
garden
and
can't
get
any
pci
data.
This
is
the
PCI
guy
at
at
this
large
corporate.
A
So
what
the
behavior
they're
looking
for
in
this
kind
of
labeling
model
is
a
container
can't
talk
to
anything
until
it
identifies
tell
a
developer
says,
is
a
PCI
work
loader
and
on
pci
workload,
and
then
that
constrains
it
to
within
the
right,
trust
realm
and
there's
a
third
state
which
is
PCI
border
in
that
you
know,
goes
through
manual
reviews
and
that
kind
of
stuff.
Any
questions
on
what
we've
been
talking
about.
This
raise
any
questions.
People
you
know,
I,
think
this
is
absolutely
bizarre
and
come
on
who
thinks
crazy?
A
So
this
actually
leads
to.
Another
question
is:
what
is
the
conversation
I
think
we've
touched
on
it
already
a
little
bit.
What
is
the
conversation
that
needs
to
happen
between
the
guys
who
own
security
and
Policy
and
the
developers
you
know
it,
because
if
this
is
a
developer,
driven
environment
to
a
certain
degree
and
in
if
we
take
this
model
to
its
logical
conclusion,
developers
are
the
ones
that
are
asserting
the
functions
of
these
things
and
and
identifying
them
and
triggering
policy.
E
Go
ahead,
so
a
lot
of
others
being
discussed
is,
if
you
look
at
OpenStack,
they
would
call
it
tenants.
Your
applique
plication
will
complete
talent
and
have
full
separation
between
those
pieces.
Do
you
see
this
world
going
to
a
world
where
developers
have
control
within
their
own
talent
network
of
our
own,
with
their
own
little
sandbox
and
then
multi-tenancy
within
the
cloud
I.
A
Think
that's
an
interesting
one.
Oh
I
guess
the
first
question
that
pops
into
my
mind
is
is
tendency
not
just
another
policy
concept.
Ie
containers
that
belong
to
tenant
a
are
forcefully
tagged
if,
if
necessary,
10
at
a
and
then
there's
some
based
policies
for
10
a
day,
you
can
talk
to
today
and
can't
talk
to
anything
else.
Same
thing
for
tenant
be
tenancy.
That's
one
way
of
thinking
about
that
is
the
tenancy
is
Tennessee
becomes
now
a
artifact
of
the
orchestrator
rather
than
artifact
of
the
infrastructure.
C
E
Tagging
is
no
matter
developers,
so
if
you
have
tenancy,
can
I
have
the
tenant
infrastructure
be
owned
by
the
security
folks
and
weave
in
antenna.
You
can
then
run
at
the
developer
control
that
right,
if
you
have
put
them
in
that
working
for
tenant,
IP
spaces
blow
the
separation
between
corporate
security
and
developers,
com
very
obvious,
so
it's
a
it'll
require
I
almost
times
you
can
do
tags.
If
you
have
talons
and
have
you
ever
very
natural
split
between
who
owns
what
about
a
boundaries
are.
B
E
C
B
E
A
Right
so
it
is
there
a
coup,
bearnaise
instance
per
tenant
or
is
Cooper
Nettie's,
the
global
management
plane
and
then
tenancy
is
a
construct
either
within
the
orchestrator
or
the
provisioning
system
or
whatever
I
think.
That's
the
correct
approach
as
an
X
operator
of
really
big
infrastructure,
I
hate,
creating
islands,
because
I
will
inevitably
provision
those
wrong
and
if
I
have
separate
Islands
I
now
have
the
issue.
B
I
mean
I
think
one
of
the
things
too
about
so
I
think
multi
tendency
is
kind
of
a
blurry
concept
for
a
lot
of
people.
It
isn't
very,
very
well-defined.
So
I'm
a
bit
really
big
fan
of
your
work
hours
on
a
dental
with
clear
containers.
I
think
that
a
concern
in
multi-tenancy
is
having
a
very
strong
security
boundary
around
your
application
unit,
which
which
you
know
with
with
clear
containers-
and
you
know
with
with
with
with
rocket
using
kvm
tool
as
well.
I
believe
in
other
systems
that
are
that
are
container
on
times.
B
You
know
running
OpenStack
on
Cooper
Nettie's
as
an
application
and
other
other
other
systems,
so
I
think
as
Cooper
Nettie's
matures
more
in
various
areas
may
be
as
clear
containers
become.
As
one
of
these
pluggable
container
run
times
in
goober
Nettie's.
We
can
actually
start
to
see
more
support
for
running
very
strong
Multi
multi
tendency
models
inside
of
inside
of
Cooper
Nettie's
itself.
You.
A
A
It's
part
of
the
standard
design
template
for
a
containerized
cloud
native
world,
so
you
know
please
when
we
say
Kuber
Nettie's
purse,
that
as
Kuber
Nettie's
an
example
not
this
is
a
coup,
burnetii
specific
thing
and
and
it's
different
for
everyone
else,
because
I
think
that's
not
the
case.
There's
robust
conversations
going
on
in
the
industry
right
now
about
you
know
what
the
other,
what
you
know
it
may
so,
DCOs
and
and
the
docker
stack
and
OpenStack
and
and
all
the
other
platforms
out
there
are
doing
in
this
space.
A
C
One
little
bit:
okay,
I
slip
in
at
the
end,
so
the
question
we
were
kind
of
kind
of
halfway
in
before
I
ran.
How
does
how
does
the
conversation
change
with
security
as
you
move
to
as
you
move
to
a
cloud
native
world,
this
one's
something
that's
particularly
near
and
dear
to
me
as
box,
is
definitely
moving
moving
along
this
path
and
I
think
really,
at
the
end
of
the
day,
I'll,
let
you
in
on
a
secret
security
teams,
have
wanted
the
same
thing
since
the
dawn
of
time.
C
They
they
want
to
keep
applications
compartmentalized
sufficiently
so
that
if
one
gets
attacked
or
breached
in
some
way
that
you
can't
pivot
to
other
parts
of
the
infrastructure
and
kind
of
contain
that
blast
radius,
they
want
the
exact
same
thing
in
a
cloud
native
world.
They
just
you,
have
a
whole
new
tool
set.
So
so,
where
is
security
in
a
cloud
data
world?
It's
the
same
place?
That's
always
been
it's!
It's
looking
at
the
full
stack
trying
to
figure
out.
A
I
think
that
I'm
going
to
make
a
statement
rather
than
turning
it
into
a
question.
Some
people
in
the
industry
have
talked
about
how
cloud
native
or
containers
allows
the
developers
to
wrench
power
back
from
the
operations
teams.
We
have
security,
networking
infrastructure,
etc,
and
that
has
a
very
I
think
bad
view
of
the
world.
That's
a
zero-sum
game.
There's
a
certain
amount
of
power
or
capability,
and
if
I
get
more,
you
get
less
I.
A
Think
what
cloud
native
does
the
ability
to
tag
things
and
label
things
and
make
the
infrastructure
responsive
to
those
it
actually
becomes
a
net
benefit
for
everyone
as
an
operator
of
infrastructure,
before
I
hated
getting
tickets
or
having
my
people
get
tickets,
saying
I
need
a
router
between
these
two
things
like.
Why
do
you
need
a
router?
Is
that
you
need
content?
You
need
to
put
a
firewall
in
there.
I
lose
all
the
context
of
what
the
developer
was
trying
to
do.
A
He's
just
saying,
because
he's
trying
to
be
a
network
engineer,
because
I
forced
him
to
do
that
if
instead
so
he's
frustrated,
because
he
has
to
wait
for
the
ticket
to
be
resolved.
I'm
frustrated
because
I
don't
really
know
what
he's
trying
to
do
so.
I
just
meet
the
terms
of
the
ticket
as
it
stands,
it's
the
way
we
communicated
now
what
we
allow
you
to
communicate
a
saint.
This
is
one
of
these
things.
This
thing
needs
to
have
this
kind
of
connectivity,
how
it's
done!
A
How
it's
protected
is
not
my
as
a
developer,
leaving
that
to
you
so
I
now
can
actually
get
the
developer
and
I
can
see
exactly
what
the
developer
needs
and
whatever
the
best
way
of
doing
that
internally
in
the
fabric.
At
this
point
in
time,
I
can
do
later.
If
I
come
over
the
different
way
of
doing
it.
I
can
do
that
and
not
break
things.
Don't
leave
those
old
firewall
rules
so
to
speak
in
there.
So
I
think
the
cloud
native
isn't
a
developer's
when
infrastructure
loses.
A
I
think
we
both
now
have
a
better
way
of
communicating
to
reach
the
same
goal.
In
this
case
you
know
securing
infrastructure
limiting
blast
radius,
because
now
we
both
understand
what
the
applications
are
doing
and
what
the
requirements
are.
So
I
think
this
is
a
net
win
for
not
just
developers,
but
also
for
the
infrastructure
and
the
security
and
the
networking
teams,
and
with
that
any
other
comments.
Otherwise
I'll.
Let
you
guys
go
for
lunch
and
thank
you
for
attending
cool
all
right.