►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Keynote: Modern Least Privilege with DevSecOps - James Watters, CTO, VMware Tanzu
A
Thanks
for
joining
me
from
san
francisco
today,
I'm
on
a
zoom
I
wish
I
was
in
a
room,
but
here
we
are,
and
I
appreciate
any
feedback
and
some
of
these
ideas,
I'm
just
starting
to
scratch
them
down
and
hopefully
we'll
both
have
a
good
time.
Kicking
this
around
so
hit
me
on
twitter,
I'm
at
waters
james.
If
you
watch
this,
let
me
know
you
saw
it.
Let
me
know
what
you
think
thanks
so
much
we'll
keep
it
fun
like
that
next
slide
here.
A
So
everywhere
I
go
over
zoom
today
you
know
I'm
running
into
more
and
more
teams
that
consider
themselves
essentially
the
platform
teams
of
these
organizations
and
they're,
not
pure
infrastructure
teams
and
they're.
Not
you
know
if
you
were
pure
application
teams
their
their.
You
know
reason
for
being.
Is
that
they're
connecting
developers
to
infrastructure
in
a
secure
pipeline,
typically
using
kubernetes
as
the
final
infrastructure
api
and
I'm
seeing
you
know
a
convergence
in
enterprises
at
least
where
security
has
always
been
a
paramount
value.
Essentially,
you
know
the
definition
of
an
enterprise.
A
Is
you
become
an
institution
and
the
first
job
of
an
institution
is
survivability
sustainability.
In
some
sense-
and
so
this
focus
on
devsecops
has
been
really
strong
in
these
platform
teams
and
I'd
say
about
60
of
the
organizations
I
mean
there's
now
someone
carrying
a
director
of
devsecops
title.
So
in
some
ways
that's
a
new
and
exciting
thing,
and
I
think
it
reflects
that
organizational
patterns
have
changed.
Our
security,
culture
and
methods
are
evolving
to
meet
modern
applications.
A
We
want
the
continuous
delivery
of
features
we
want
to
be
able
to
respond
to
a
user
need
in
days
or
under
a
week
versus
on
a
more
waterfall
six-month
three-month,
two-month
schedule
and
we'd
like
to
see
those
changes.
You
know
make
their
way
to
production
for
feedback
to
the
developers
as
rapidly
as
possible.
A
So
this
is
a
time
of
great
adaptation
to
this
era
of
microservices,
continuous
delivery,
containerization
and
there's
a
ever
growing
focus
on
concepts
of
things
like
xero
trust.
Now
that
we've
got
these
distributed,
microservices
and
you're,
suddenly
adding
all
of
this
network
networking
into
the
core
business
logic
of
an
application.
A
Well,
how
do
we
build
our
application
level
networks
before
you
know
a
java
program,
1200
functions
running
and
one
jvm.
A
You
understood
the
privilege
model
of
that
application
because
it
was
all
inherently
one
application,
but
now
you've
introduced
networking
and
so
the
idea
of
the
zero
trust
heavily
identity,
centric
network
has
come
into
play
and
in
some
ways
that
feels
like
a
new
fresh
take
on
how
we
should
do
networking,
but
in
some
sense
I
think,
that's
also
not
true,
and
we've
been
on
this
trend
of
least
privileged
for
a
long
time.
A
In
fact,
if
you
go
back
to
you
know,
acm
journals
in
the
early
70s.
There
were
people
articulating
this
idea
of
least
privilege,
then
the
idea
that
every
program
and
every
privileged
user
of
the
system
should
operate
the
least
amount
of
privilege
necessary
to
complete
the
job,
and
I
think,
while
in
some
sense
the
internet
was
really
not
about
least
privilege,
because
the
internet
was
built
for
collaboration
and
sharing
like
http
smtp.
These
were
protocols
really
meant
to
say
here's
some
content.
A
I
want
to
share
with
you
and
that's
a
great
quote
from
the
woman
who
founded
yubikey,
where
she
said:
hey
we're
now
trying
to
retrofit.
A
You
know
kind
of
identity
and
access
management
and
controls
into
an
organ
into
a
series
of
protocols
built
for
sharing
and
collaboration
first,
but
if
you
think
of
the
cloud
really
as
a
modern
at
scale
continuously
delivered
model
of
what
the
mainframe
really
was
providing
in
the
70s,
this
articulated
articulation
of
least
privilege
starts
to
make
sense,
and
you
can
start
to
look
at
some
of
the
zero
trust
networking
devsecops
a
lot
of
these
modern
security
practices
as
bringing
cloud
computing
back
into
that
era
of
design.
A
And
I
think,
as
I
think,
back
over
the
last
10
years
that
I've
worked
in
computing,
I've
always
seen
security
and
especially
designs
of
enterprise
systems-
that
favor
least
privilege
to
be
highly
attractive,
and
I
like
to
think
about
this
quote
from
jeff
bezos,
where
he
basically
articulates
that
everyone
talks
about
what
will
change
over
the
next
10
years.
But
what
you
can
really
build
on
is
what
won't
change
and
I
think,
as
I
think,
over
the
last
10
years,
that
I've
been
working
on
cloud
native
systems.
A
The
idea
of
least
privilege
and
high
security
has
been
something
I
consistently
bet
on,
and
our
organization
has
consistently
bet
on
successfully.
We
took
you
know,
articulate
it
more.
We
took
one
bank
from
you
know
on
average,
a
six-month
wait
for
patching
of
their
core
systems
and
platforms
to
about
an
every
three-day
pace,
because
we
made
it
a
first-class
object
of
the
system.
They
were
using
of
the
platform
they
were
using
and
they
were
so
excited
about
it.
The
cio
is
excited
about
it.
A
Everyone
was
excited
about
it
and
someone
asked
me
once
they
said.
Well,
you
know:
how
did
you
know
to
design
for
security?
How
did
you
know
to
make
security
a
focus
of
that
microservices
platform
and
actually
was
pretty
inarticulate
at
the
time
it
was
almost
like
a
fish
and
water.
I
had
been
so
close
to
enterprises
that
always
favored
this
model
that
I
wasn't
able
to
be
crisp
about.
Why?
A
But
I
think
this
idea
of
least
privilege
coming
to
cloud
native
is
an
important
articulation
of
why
enterprises
really
want
to
bet
on
this
for
the
next
10
years
as
well,
and
what
we
saw
with
the
first
generation
of
our
cloud
native
designs
was
that
we
were
able
to
articulate
and
expose
the
right
set
of
interfaces
such
that
we
achieved
what
we
called
at
the
time.
The
three
r's
and
those
are
still
really
important.
A
If
a
cve
came
out,
we
would
automatically
do
a
rolling
update
of
that
system,
so
one
node
at
a
time
would
be
replaced.
Declaratively
a
manifest
would
inspect
version.
One
versus
version
two
see
the
diff
and
apply
the
diff,
and
we
did
that
the
entire
way
from
the
operating
system
up
to
some
of
the
application,
runtime
vulnerabilities,
so
anytime,
a
repair,
you
know
event
hit
the
system
it
would
be
replaced.
A
We
would,
as
part
of
that,
repair,
also
recreate
those
immutable
images
from
scratch,
and
so
organizations
were
much
more
comfortable
that
the
platform
they
were
consuming
was
free
of
malware
because
we
were
always
rebuilding
from
sign
source
and
people.
You
know
as
high
up
as
cios
and
major
banking
organizations
now
swear
by
this
repaving
model
where
they're
like
every
week,
we
rebuild
every
node
in
the
system,
and
I
think
this
is
a
really
important
part
of
it
of
modern
application
platform.
A
Security
designs
we'd
also
build
as
much
as
possible
of
you
know
the
controls
right
into
the
standard
developer
experience.
So,
as
you
went
to
execute
a
pipeline,
say
10
out
of
12
controls
were
embedded
in
the
process
already,
so,
while
the
developer
might
be
responsible
for-
and
you
know,
ensuring
some
of
the
controls
were
still
met.
A
lot
of
them
were
automated
and
part
of
the
developer.
A
Experience
and
finally,
you
know
if
anyone
who's
seen
some
of
the
postmortem
on
the
equifax
study
knows
that
you
know
letting
secret
space
credentials
languish
in
the
system
or
be
exposed
in
plain
text
or
persist
is
a
really
dangerous
thing.
A
lot
of
the
exploits
we
see
come
come
down
to
the
acquisition
and
exploitation
and
privilege
escalation
of
these
credentials.
So
we
really,
you
know,
fashioned
our
platform.
After
idea
that
constantly
anytime
a
node
would
be
touched,
we
could
rotate
the
credentials.
A
I
think
of
the
checklist
sort
of
like
this
at
a
baseline,
of
course,
immutability
and
manifest
based
deployments,
so
that
governance
and
controls
are
very
clear
and
explicit.
So
that's
a
baseline,
but
I
don't
think
it's
enough.
I
really
think
this
trend
towards
a
high,
a
more
highly
ephemeral
system,
is
part
of
modern
least
privilege.
I
think
time
has
entered
out
as
a
dimension
of
how
long
something
should
even
exist
is
almost
in
a
sense
part
of
the
metaphor
of
privilege,
the
shorter
something
shorter.
A
Something
is,
you
know
available
the
less
time
anyone
trying
to
exploit
it
could
exercise
its
privilege,
and
so
the
idea
that
nodes
should
be
rebuilt,
constantly
replicated
from
sort
of
a
sign
source
model
of
the
original
intention
is
important.
A
The
identity
of
that
short
lived,
node
is
also
important,
and
I
think
in
tanzania
we're
tilting
away
from
this
idea
of
these
shared
secrets,
sort
of
like
the
aftermarket
secrets.
You
know,
model
versus
more
of
an
inherent
strong
ephemeral
identity
baked
into
the
platform
with
things
like
spiffy
inspire,
I'm
very
excited
about
some
of
the
demonstrations.
I've
seen
where
more
of
an
event-driven
vulnerability
management
I'll
talk
a
little
bit
about
build
packs,
but
as
a
vulnerability
is
found,
the
build
pipeline
is
automatically
updated.
A
In
some
cases,
the
application
is
automatically
updated
to
remove
that
vulnerability.
So,
ideally,
just
like
that
jeff
bezos
statement,
we
should
be
converging
to
zero
time
between
vulnerability,
discovery
and
vulnerability.
Patching
in
the
system,
if
possible,
enterprises
are
always
going
to
want
a
shorter
and
shorter
time
between
the
discovery
of
a
vulnerability
and
the
replacement
of
it
in
a
safe
way.
A
And
finally,
one
of
the
biggest
things
we've
seen
is
this
merge
of
devx
and
control
is
super
powerful,
so
by
paving
the
path
for
developers
by
giving
them
a
set
of
conditions
by
which
they
can
get
code
to
production
quickly
that
also
meet
compliance
and
security
needs.
It's
an
incredible
one,
plus
one
equals
five
so
see.
These
are
some
of,
I
think
the
modern
principles
of
least
privilege
that
I'm
going
to
keep
riffing
on
and
looking
to
encourage
all
of
our
teams
building
tonsil
around.
A
Let
me
give
you
some
examples
of
where
I
think
this
is
going
to
take
off
and
I'll
close
with
that.
I'm
super
excited
about
the
ephemeral
node
model
of
k-native
that
scales
to
zero
because,
as
you
start
to
articulate
an
application
as
more
of
the
serverless
model,
where
you've
got
an
api
or
a
route
and
then
you've
got
a
series
of
revisions
and
you
can
constantly
restart
that
node
based
off
of
traffic.
A
Well,
that
gives
us
the
opportunity
to
refresh
the
node
to
make
it
more
ephemeral
to
make
sure
this
identity
is
short-lived,
so
I
think
building
applications
that
fit
the
serverless
canadian
model.
First,
when
possible
is
super
exciting
and
we're
looking
to
bring
a
modern,
devx
the
whole
way
to
this
k-native
model,
and
I
think
this
application
pattern.
A
This
modern
microservices
pattern
mixed
with
modern
security
practices
together,
is
super
powerful
because
it
allows
that
three
hours
model
of
security
to
come
into
the
next
generation
of
platform
designs,
and
we
can
start
to
say,
shorter
and
shorter
time
to
lives
for
all
the
nodes,
identities,
secrets,
excess,
etc.
On
the
platform,
we're
also
going
to
bring
a
modern
software
supply
chain
to
to
the
k-native
experience,
so
the
tons
of
build
service
and
the
modern
software
supply
chain
we're
building
with
it.
Let
me
just
give
you
a
quick
highlight
of
why
I
think
that's
so
important.
A
By
default,
a
developer
should
not
have
to
craft
a
python
microservice
or
a
java
microservices
docker
file.
In
a
sense,
that's
a
real
violation
of
lease
privilege.
Instead
of
just
having
the
the
the
application
be
deriving.
The
docker
image
through
the
build
service,
the
build
service,
runs
a
process
and
build
pack
called
detect,
compile
it
detects
what's
in
the
application,
what
it
needs
and
it
compiles
in
a
safe
and
secure
way.
A
She
no
longer
is
crafting
her
own
custom,
docker
image
and
the
vulnerabilities
are
automatically
updated.
I
think
that
fits
that
modern
model
of
least
privilege
of
devsecops.
So
it's
super
exciting
we're
seeing
people
almost
debate.
What
build
service
is,
is
it
a
security
layer
or
is
it
a
devex
later?
Is
it
a
speed
layer?
We
have
some
organizations
calling
it
all
three
and
all
three
are
right,
and
that's
that
magic,
convergence
of
developer
experience
and
controls
that
I
think
are
made
possible
through
this
new
server-less
model
of
applications
and
platforms.
A
We
want
to
bring
that
same
os,
patching
speed
and
alacrity
in
a
declarative
fashion
that
we
had
in
generation.
One
platform
designs
to
tonzu
and
to
our
next
generation
of
systems,
and
so
we're
working
with
some
of
the
same
customers
that
did
that
continuous
rebuild
of
their
operating
system
to
bring
os
management
and
os
update
to
cluster
api.
So
now
we've
got
the
kubernetes
native
cluster
api
way
of
articulating
configurations.
You've
got
that
declarative
config.
The
os
is
just
baked
into
it.
A
So
as
the
I,
as
rolls,
the
node
you're
rolling
the
os
and
building
the
event
and
alerting
model
around
when
that
os
needs
updated
and
patched
right
into
our
platform
is
an
important
part
of
this
modern
security
posture.
A
So
imagine
the
oneplus
one
here
of
a
k-native
style,
serverless
application
and
then
a
cluster
api
managed
os
anytime,
that
you
want
to
update
that
os.
Your
application
is
always
ready
for
a
restart
because
it's
inherently
scale
out
scale
to
zero.
So
applying
these
updates
becomes
really
intuitive
and
proven
operational
model
for
the
platform
team,
so
that
devsecops
team
can
say
if
there's
a
vulnerability
in
either
the
application
in
the
build
pack
or
in
the
os
and
in
kubernetes
between
cluster
api
and
the
buildpack
model.
A
A
It's
never
fast
enough,
really
quickly
touching
on
this
there's
some
things
that
aren't
custom
applications
for
things
that
aren't
custom
applications
for
things
that
are
packaged
open
source.
A
We
have
a
secure
pipeline
that
builds
something
called
the
tonzo
application
catalog
to
give
you
providence,
proven
proof
of
testing
open
source
deployed
to
production
with
confidence
we
have
so
many
people
that
are
saying:
oh,
we
used
to
go
out
and
just
grab
any
open
source
off
the
web,
compile
it
ourselves
we're
now
trusting
this
proven
software
supply
chain
from
the
tanzania
application
catalog
to
surround
our
customer
applications
with
that
code.
A
The
last
thing,
then,
though,
is
that
you
know
these
microservices
running
in
containers
or
apps,
often
apps,
and
so
we're
building
into
the
spring
framework.
More
and
more
out
of
the
box
devx
around
security-
and
I
won't
cover
it
all
today,
but
I'll
give
you
a
quick
preview
of
where
we're
headed
there.
A
If
you
think
about
that
k-native
server-less
application,
it
starts
to
expose
an
api,
and
you
really
want
to
mix
the
best
of
api
management
and
microservices
management,
and
in
the
past
we
saw
that
there
were
separate
teams,
one
that
was
running
the
application.
Another
was
running
the
api
security
team
and,
if
you
wanted,
you
know
strong
authentication
rate,
limiting
routing
or
security
controls
on
that
application,
say
anomaly:
detection
of
the
application
and
api
behavior.
You
had
to
have
one
team
separate
from
the
other,
so
we're
doing
two
things
there.
A
We
think
this
lease
privilege
also
applies
to
the
applications
models
as
well.
We
think
that
every
microservices
should
have
full
api
security,
both
in
terms
of
a
micro
gateway
to
protect
it
from
ddos
attacks
with
rate
limiting,
should
have
strong,
oidc
integration
for
authentication
and
then
we're
taking
that
even
further
than
just
the
spring
gateway
itself,
and
we
made
an
acquisition,
a
company
called
mesh
seven
and
now
we're
starting
to
take
what
used
to
be
the
exclusive.
A
You
know,
capabilities
of
these
api
security
gateways
and
we're
bringing
that
into
the
envoy
ecosystem
into
the
cloud
native
ecosystem
and
we're
saying
with
the
extensible
you
know
envoy
model.
Could
we
bring
an
over
time
potentially
even
awesome,
compatible
ecosystem
of
security
and
observability
features
to
every
envoy
such
that
every
microservice
can
be
protected
as
it's
created
within
kubernetes,
as
opposed
to
that
being
a
separate
job
of
an
api.
Only
team
and
I'll,
just
close
with
this
example
of
why,
I
think
that's
another.
A
You
know
the
endless
demand
for
security
within
enterprise
is
always
bringing
that
closer.
That
devsecops
model
we've
talked
to
some
organizations
where
they
might
have
2000
apis,
but
only
800
of
them
formerly
protected
by
their
api
management
team.
And
the
reason
was:
is
that
that
api
management
team
wasn't
as
close
to
the
sdlc,
to
container
management
to
that
devsecops
pipeline
team,
but
now
with
mesh
7
and
the
spring
gateway,
we
think
we
can
bring
all
of
the
security
and
control
and
observability
of
those.
A
You
know:
enterprise,
api
management
tools
to
every
microservice
and
what's
a
microservice,
what's
an
api,
they
have
the
superpowers
of
each
other
immediately,
so
you
can
deploy
with
the
speed
of
microservices
and
the
security
and
control
of
an
api
all
in
one.
So
we're
really
excited
about.
You
know
kind
of
that
roadmap,
bringing
this
least
privilege
this
endless
demand
that
enterprises
want
to
be
more
and
more
secure
every
day
to
every
application.
So
that's
a
little
bit
of
my
current
thinking.
A
You
know
I'm
pretty
excited
about
looking
to
bring
that
model
to
our
modern
application
platforms
on
kubernetes
and
I
think
it's
an
extension
really
of
a
trend
we've
seen
for
a
long
long
time,
but
we're
bringing
to
this
distributed
application
model.
So
it's
an
exciting
time
to
work
on
distributed
applications
container
applications.
As
we
start
to
bring
some
of
the
security
we
might
have
had
to
consolidated
monoliths
into
consolidated
systems
to
our
distributed
systems.
So
thanks
for
listening
in
the
talk,
throw
me
a
tweet.