►
From YouTube: Where to begin your dev centric cloud infosec journey
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
I'd
like
to
thank
everyone
for
joining
us.
Welcome
to
today's
cncf
live
webinar,
where
to
begin
your
dev
centric
cloud,
infosec
journey,
I'm
libby,
schultz
and
I'll
be
moderating.
Today's
webinar
we'd
like
to
welcome
our
presenters
today,
guy
eisenkott
product
management
and
ashley
ward
technical
director,
both
with
palo
alto
networks,
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak
as
an
attendee.
A
There
is
a
chat
box
at
the
top
right
of
your
screen
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
A
B
Thanks
very
much
libby,
so
yes,
here
we
are
thanks
to
cncf.
We
have
this
presentation
now
what
it's
entitled,
where
to
begin.
Your
dev
centric
cloud
infosec
journey,
but
when
is
infosec
ever
meant
to
have
been
dev
centric.
Isn't
this
just
pandering
to
developers
who
should
have
been
making
their
work
security
centric
from
the
beginning,
I'm
ashley
ward,
I'm
technical
director
of
the
office,
the
cto
and
with
me,
though,
is
guy
eisencock.
B
I
is
actually
a
senior
director
product
management
he's
the
one
who
knows
what
he's
talking
about
instead,
I'm
just
the
aggressive
angry
one
in
this
conversation,
so
guy
here
we
have
a
cut
out
from
the
cncf
landscape
of
security
companies.
There
are
oodles
of
them.
We've
got
security
everywhere,
any
different.
Little
bit,
you
might
want,
there's
a
security
company.
So
what's
the
problem.
C
C
Yeah,
good
luck,
I'll
I'll
I'll
say
this.
I
think
what
what
I
think
is
very
interesting
about
the
landscape
is
that
it
really
demonstrates
the
fact
that
we
have
developers
on
both
sides
of
the
aisle.
C
We
have
security
developers
that
are
working
tirelessly
to
try
to
inject
their
long
thought
processes
and
how
to
eventually
implement
security
controls
on
a
on
a
very
rapid,
deploying
rapid,
rapidly
growing
ecosystem
and
on
the
other
hand,
you
have
a
growing
populations
of
developers
and
application
developers,
web
developers,
infrastructure
developers
that
have
hands-on
access
to
the
core
infrastructure,
that's
going
to
run
applications
for
the
some
of
the
biggest
companies
in
the
world.
C
So
what
happens
when
you
have
talented
developers
on
both
sides
of
the
spectrum
is:
is:
is
this
fantastic
landscape,
where
companies
and
individuals,
even
and
in
the
individual
communities,
identify
very
granular
pro
problem
spaces
and
tackle
them
head-on
as
a
developer?
Sometimes
you
don't
have
the
privilege
to
whine.
You
have
the
privilege
to
try
to
solve
things
as
they
are.
Maybe
I'm
being
too
optimistic
here.
But
what?
What?
What
are
your
thoughts
on
on
how
wide
this
landscape
is?.
B
C
Yeah
good
good
question:
I
don't
want
to
boil
this
down
into
into
something
that's
being
too
too
simplistic,
but
I
I
think
really
that
the
title
of
this
this
talk
is
going
to
be.
Not
only
what
should
you
do,
but
where
do
you
start?
C
I
think
a
lot
of
a
lot
of
people,
maybe
that
that
are
attending
this
talk
and-
and
I've
definitely
been
on
this
trail,
starting
starting
our
startup
about
two
and
a
half
years
ago
is
what
is
going
to
be
best
of
breed
and
what's
going
to
be
good
enough
when
you,
when
you
want
to
build
an
enterprise,
great
web
application,
that's
hosted
on
the
public
cloud
and
one
of
the
complicated
things
as
a
developer
coming
into
this
space.
C
Is
that
there's
so
much
to
choose
from
and
there's
going
to
be
so
little
that
you
can
trust
an
external
vendor
or
a
third-party
service
provider?
To
give
you
compared
to
things
that
you
can
either
mix
and
choose
and
build
your
own
best
of
breed?
So
if
I'm
speaking
to
my
myself
two
and
a
half
years
ago,
as
a
technology
leader
and
a
product
leader,
I
think
the
biggest
challenge
has
been.
Where
do
I
actually
start?
If
I
want
to
build
really
secure
cloud
infrastructure.
B
See
now
that
is,
that
is
interesting,
because
actually
one
of
the
things
I
was
then
going
to
hit
you
with
was
that
well,
actually
the
research
has
been
done
to
show
that
we're
not
getting
there.
I
know
our
palo
alto
networks
have
a
unit
42
research
department,
but
there's
also
the
bridge
crew
research
as
well,
of
course,
which
is
just
as
valid.
I
may
come
up
with
these
numbers
now.
B
I
I
always
worry
when
we
display
numbers
like
these,
that
we're
trying
to
fear
monger,
and
so
I
immediately
go
we're
not
trying
to
fear
monger
we're
trying
to
say
that
the
issue
exists,
but
so
these
seem
like
really
simple
things.
Guy
I
mean
I
I
get
that
we're
still
not
doing
them,
but
you
know
I
speak
to
csos
regularly
and
I
see
so
would
look
at
this
and
say
well.
Why
isn't
this
happening?
Shouldn't
people
just
know
to
make
sure
that
cloud
databases
should
be
encrypted.
I
mean
what.
Why
is
this?
C
Yeah
and
I
think
you're
you're,
going
to
to
take
the
side
of
the
security
practitioner
in
this
conversation
I'll
try
to
take
the
position
of
a
developer
or
again
a
technology
or
an
architecture
leader.
I
think
what
research
that
we've
done
internally
in
bridger
and
now
we've
we've
seen
done
on
unit
42
and
others
is
just
take
a
look
at
these
consistent
numbers
where,
where,
if
we
lay,
we
look
at
configurations,
we
look
at
vulnerable
images.
C
We
look
at
misconfigurations
on
on
our
centralized
artifact
or
public
artifacts
for
for
for
helm,
charts.
You
can
see
these
ecosystems
are
consistently
misconfigured,
but
not
because
of
human
error,
for
the
other
exact
reason
we're
trying
to
make
it
dead,
simple
for
developers
to
ramp
up
from
zero
to
a
working,
a
functioning
cloud
environment
using
boilerplate
templates.
C
So
whether
that's
a
boilerplate
template
you
capture
from
github,
whether
that's
a
boilerplate
chart,
you
get
from
artifact
hub
you're
bound
to
get
a
configuration
which
will
only
bring
you
thus
far
into
a
running
of
working
hello
world,
and
what
happens
is
that
those
boilerplates
are
sometimes
not
treated
as
such,
and
this
is
across
multiple
ecosystems.
In
our
in
our
landscape,
they
are
getting
consistently
misconfigured.
C
B
You
know
a
developer
and
a
security
person,
and
we
all
have
these
nice,
it's
easier
to
have
these
slots
for
things,
but
in
fact,
that's
not
that's
not
how
things
work
we're
in
such
a
huge
field
and
such
a
huge
subject
that
you're
not
going
to
be
an
expert.
Not
all
of
these
different
areas
and
and
and
really
you
shouldn't
be-
I
mean
somebody
who's
building
a
platform
is
going
to
have
different
priorities
to
someone
who's.
B
You
know
building
an
application,
even
though
both
of
them,
if
they're
developing
code,
are
developers
at
the
end
of
the
day.
You
know
so.
No
I
find
that
really
interesting.
So
we
we
have
again
more
more
research
driven
information
because
that's
you
know
that's
how
we,
how
we
want
to
do
things.
B
C
We'll
get
to
some
practical
examples
later
on,
but
just
take
a
look
at
networking
as
an
example.
So
if
you
remember,
you
know
if
you,
if
you
had
an
on-prem
data
center,
just
what
two
three
four
years
ago,
we
had
networking
engineers
that
their
sole
purpose
for
us
as
business
owners,
was
to
go
out
and
capture
best
of
breed
infrastructure
and
essentially
hardwire
configure
it
in
a
way
that
really
makes
make
sure
that
what
needs
to
be
inside
stays
inside
and
what
needs
to
be
outsized
stays
outside.
C
And
what
cloud
native
has
done
specifically
for
the
role
of
the
networking
engineer.
It's
essentially
democratized
democratized
it
a
microservice,
can
essentially
become
a
a
networking
edge
in
a
flip
of
a
button,
and
what
we
saw
from
our
terraform
studies
is
that
it's
it's
not
just
you
know,
if
you
think
of
something
like
a
security
group
concept,
which
is
the
aws
equivalent
of
a
firewall
rule,
that's
not
enough
to
get
you
protected.
If
you
want
a
specific
workload
to
be
private
and
not
public,
you
have
to
be
cautious
of
everything
else.
C
That's
going
to
wrap
around
your
compute
instance,
whether
that's
the
security
group
internally
and
then
you're
going
to
have
your
vpcs.
The
way
that
your
accounts
are
set
up.
Peering,
there's
a
bunch
of
different
ways
to
make
connectivity
work
in
a
public
cloud
and
that's
just
aws
and
terraform
is
a
surface.
C
What
happens
is
what
happens
now
when
you
have
those
microservices
set
up
as
individual
networking
nodes
that
suddenly
have
their
own
networking
capacity
and
networking
interfaces
and
that's
where
we
move
right
to
the
kubernetes
side
right
and
that's
that
that's
a
that's
an
entirely
different
world
where
networking
is,
is
completely
extracted
through
through
networking
interfaces
and
there's
tons
of
great
projects
that
are
now
trying
to
help
us
go
through
the
barrier
of
the
deprecation
of
things
like
network
policies
and
start
to
go
to
a
more
a
more
standardized
future
with
with
with
some
some
great
insights
into
into
how
you
can
consistently
invoke
networking
on
on
a
variety
of
different
edges
on
on
your
networking
cloud.
C
But
networking
is
not
alone
right.
You
mentioned
databases,
that's
that's
another
one!
So
I
think,
we're
past
the
point
where
we
have
the
notion
that
we
need
to
maybe
encrypt
or
or
just
I
use
use
standalone.
Networking
excuse
me,
databases
that
retain
data
in
a
way
that
that
is
consistent
with
with
how
we
want
to
preserve
private
information
as
an
example.
But
databases
are
also
becoming
this
entire
world,
where
it's
not
just
the
dba
that
controls
the
configuration
of
the
database.
C
B
You
know
you're
so
right,
and
the
sad
thing
is
is
that
that's
these
were
all
things
that
were
abstracted
away
or
rolls
or
shoulders
of
giants
that
were
you
know
people
did
before
I
I
smiled
there,
as
you
were
talking,
because
I
have
a
very
close
friend,
who's,
who's,
a
dba
and-
and
you
know,
our
relationship
from
the
very
beginning
was
always.
He
would
come
to
me
probably
to
ask
me
for
more
file
system
storage,
because
his
database
would
just
consume
everything
that
was
there.
B
But
but
you
know
he
would
then
have
a
similar
relationship
with
all
the
different
applications
that
would
run
on
that
shared
database,
and
people
would
forget
that
actually,
there
was
a
whole
lot
of
effort
that
I
put
into
for
the
operating
system
he
put
into
from
the
the
database,
the
relational
database
at
the
time,
a
very
famous
one
that
everyone
knows
and
loves
a
relational
database,
all
the
settings
there
and
then
the
different
schemas
had
different
people
who
would
look
after
schemas,
but
you've
got
all
of
this
thought
and
intellect
that
goes
into
it,
and
you
mentioned
backups,
and
all
that
I
mean
it's
a
huge
thing
that
was
done
previously.
B
I'm
not
saying
we
go
back
to
these
glory
days
of
multiple
layers.
What
I'm
saying
is
that
a
lot
of
the
time
there
were
many
decisions
made
that
were
perfectly
in
keeping
with
stuff,
I
mean
in
kubernetes,
manifest
land
runs
as
root
or
privileged
containers
is
a.
I
watched
a
really
interesting
talk,
one
kubecon,
which
was
about
here's.
What
happens
when
you
run
a
container's
route?
Now,
as
somebody
who
who
had
root
access
and
very
proudly,
you
know
had
they
got
root
t-shirt.
That
was
me
I
had.
B
I
was
the
man
in
charge
and
as
somebody
who
did
that
to
me
having
root
was,
it
was
clear,
super
user
access,
but
actually
it
was
really
interesting.
Seeing
well
if
you
grant
root
privileges
to
a
container
and
then
have
a
container
be
able
to
make
use
of
those,
then
actually
bad
things
could
happen
and
and
the
whole
audience
loved
this
talk
and
while
I'm
going
am
I
a
dinosaur?
B
This
is,
if
you
grant
something
rude,
but
it's
because
it's
not
clear
because
that
wasn't
the
life
that
people
lived
of
having
to
manage
through
access
and
who
can
do
what
and
what
happens.
But
the
other
thing
is
you.
You
were
very
kind
and
said
that
you
know
it's
not
people
who
necessarily
do
this
for
the
kubernetes
manifest
I'll
hold
my
hand
up
and
say
that
I've
probably
done
those
top
three,
quite
happily
and
many
times
in
order
to
try
and
get
things
working
exactly.
B
I
know
I'm
all
sharing
those
networks,
one
thing
for
number:
three:
sharing
a
host
file
system.
I
think
I've
I've.
Certainly
I've
been
bad
at
doing
that
type
of
thing,
certainly
myself
so
listen.
What,
then,
is
the
answer
with
all
of
this?
What
can
we
do
to
try
and
make
things
better?
I
mean
we've
talked
around
the
problem
and
now
you
know
you
come
along
this
way,
but
I
I
don't
think
it's
just
a
tooling
thing
come
on.
What
is
it
that
we
should
be
talking
about.
C
I'll
give
you
my
my
point,
my
perspective
on
this
and-
and
I
think
you
have
your
your
individual
and
and
thoughtful
one
as
well,
but
I
I
like
to
look
at
if
we
started
back
on
the
landscape.
Now,
let's
focus
on
the
individual
team
and
and
and
we
have
this
obstruction
of
a
development
life
cycle
which
which
is
purposefully,
abstracts
away
some
of
the
complexities
of
ci
cd
pipelines
because
we're
we
want
to
start
to
think
about
development
life
cycles
as
a
spectrum.
We
have
on
our
far
left
the
development
stage.
C
We
we're
going
to
break
that
down
in
a
little
bit.
But
if
you
think
about
how
code
gets
composed
gets
collaborated
between
teams
gets
reviewed,
that's
an
entirely
new
newly
found
pros
process
that
teams
that
are
being
thoughtful
about
how
they
want
to
make
sure
that
their
their
good
code
arrives
downstream
and
not
the
bad
code
are
putting
more
and
more
emphasis
on.
C
How
do
we
create
developer
guardrails
that
are
not
restricting
us
from
building
but
are
actually
helping
us
to
prevent
the
miserable
mistakes
that
we
can
do
downstream
and
then
on
the
far
right
and
we'll
get
to
the
middle
in
a
sec?
We
have
a
run
time
and
and
from
my
perspective,
it's
usually
from
a
security
standpoint.
C
It's
really
where
it's
probably
too
late
right,
because
if
we
had
you
know
our
best
and
brightest
building
our
business
logic,
reviewing
it
analyzing
it
designing
that
it's
production
ready
testing
it.
Naturally,
by
the
moment
it
gets
into
into
runtime,
and
we
have
the
most
sophisticated
tools
out
there
that
are
trying
to
capture
the
misconfigurations
and
to
make
sure
no
one
gets
in.
Usually
the
effort
to
roll
those
back
and
make
sure
that
the
amis
configuration
is
no
longer
in
runtime
is
something
that
could
cost
us
a
lot.
C
It
can
cost
us
a
lot
in
in
our
slas
and
slos,
and
it
can
cost
us
a
lot
in
human
effort
to
make
a
a
business
logic
that
had
worked
previously
work
now
with
with
injected
insights
from
runtime.
C
And
this
is
where
that
middle
part
comes
into
the
picture.
And
that's
where
I
think
the
biggest
promise
is
over
time
is
seeing
teams
that
are
making
the
effort
to
take
that
initial
portion
of
code
review
and
making
sure
that
that
code
gets
reviewed
in
variety
of
stages,
with
proper
context
that
mimics
the
best
way
that
a
runtime
environment
will
behave,
whether
that's
in
a
cicd
process,
a
lower
grade
production,
a
pre-prod.
C
If
you
will,
those
are
the
types
of
processes
that
have
become
become
common
knowledge,
but
making
sure
that
they
get
securely
verified
and
identified
for
potential
issues.
Using
some
of
the
tooling.
That
we've
seen
previously
is
where
I
think
the
next
big
leap
in
terms
of
security
maturity.
We're
going
to
see
amongst
cloud
native
teams.
B
That's
that's
really
interesting
because,
usually
from
a
security
point
of
view,
it's
all
about-
and
I
again
I've
got
friends
who
laugh
at
me
as
soon
as
we
say,
shift
left
it's
like
I
get
paid
every
time
I
say
shift
left,
and
so
it
does
feel.
Sometimes
you
go
shift
left
is
far
left
in
fact
make
up
more
left
and
and
put
it
even
further
left
than
we
can,
but
actually
you
you've
called
out
that,
certainly
that
develop
phase
is
really
important,
but
you've
got
a
whole
lot
of
value
and
distribute
and
deploy.
B
That's
that's
really
exciting.
Now,
for
for
everybody
who's
on
this
call,
this
is
taking
that's
the
cncf
security
sig,
the
special
interest
group.
That's
the
white
paper,
we've
pulled
those
out
from
and
I
will
call
out
a
friend
of
mine,
a
colleague
actually
but
a
friend
as
well.
Vinay
was
a
co-author
on
that.
So
really
exciting.
For
that
part,
but
listen
sorry,
guy
I've
gone
on
sidetracked
again,
but
gonna
dive
into
a
little
bit
more
around
this.
For
me,.
C
Yeah,
so
if
we
we
now
double
click,
maybe
one
layer
deeper
into
into
that
previous
slide
and
give
you
a
little
bit
about
how
we
at
virtual
kind
of
tackled
it.
C
When
we
try
to
identify
the
human
and
technical
interfaces
where
it
really
becomes
very
valuable
to
start
getting
deep,
contextual
insights
around
how
infrastructure
gets
rolled
from
the
point
it,
it
was
fetched
from
a
a
module
that
was
publicly
available,
like
the
terraform
registry
or
the
artifact
hub
to
the
point
where
it
gets
deployed
in
a
production,
environment
and-
and
we
went
really
really
deep
and
we
really
wanted
to
start
with
the
individual
developers
ide
because
it
it's.
You
know,
it's
amazing.
C
Sometimes
we
forget
about
how
much
control
and
how
much
access
we
give
the
individual
developer.
When
it
comes
to
cloud
native
apps,
you
mentioned
root
access
before
in
kubernetes.
If
you
think
about
a
developer,
that's
building
a
net
new
application
from
scratch,
they're
going
to
essentially
when,
when
configuring
the
code,
that
eventually
runs
the
manifest
for
for
for
that.
For
that
kubernetes
cluster
workloads.
C
You
understand
that
a
lot
of
the
decisions
are
going
to
be
made.
Probably
weeks
or
months
before
before
that
that
gets
eventually
into
pro
so
that
root
access
that
appeared
in
runtime
on
the
end
of
the
process
actually
appears
all
the
time
on
the
individual
developers
ide.
And
when
you
go
into
that
type
of
mindset
and
you
identify.
There
is
a
lot
of
complexity
that
goes
into
building
out
secure
by
default
infrastructure.
You
identify
the
id
the
individual
developer's
id
as
an
opportunity.
C
Now
now
I'm
going
to
speak
from
a
security
mindset
and
say
we
can
give
developers
best
practices
on
how
to
set
up
their
local
environments
and
we
can
give
them
even
further
guidelines
and
details
on
what
types
of
linters
testers
verification
tools
they're
using
on
their
individual
workstations,
and
this
is
where
I
think
organizations
are
going
to
have
to
go
beyond
just
requesting
or
requiring
people
to
to
use
these
tools
on
id.
But
this
becoming
a
de
facto
standard.
B
That's
interesting
because
that's
certainly
that's
that
whole
pyramid
of
testing
and
that's
type
of
stuff
that
you
can
do
frequently
and
often,
then
you
can
do
that
in
your
ide
and
it
ties
in
again
with
that
whole
thing
you
mentioned
before,
which
is
you
know
when
we
look
at
a
developer,
there
could
be
a
developer
who's
doing
infrastructure
as
code,
and
somebody
else
is:
writing
a
a
different,
an
application
or
doing
something
there,
because
that
was
something
I
found
in
very
early
days:
writing
well
puppet
or
chef
or
whatever
at
the
time
and
about
going
okay.
B
C
Yeah
me
too,
let's
maybe
take
this
real,
quick
and
kind
of
merge
between
pre-commit
problem
regulator
and
merge,
request
processes,
and
this
starts
with.
We
have
earlier
conversation
about
github's
you
and
me,
and
we
we
talked
about
the
opportunity
that
gate
as
a
platform,
regardless
to
what
git
platform
you're
using
is
introducing
to
automated
security
testing,
and
one
thing
that
we
really
like
is
the
fact
that
we
can
invoke
a
conversation.
C
That's
triggered
by
automation,
and
that
brings
together
developers
to
make
a
decision
as
part
of
coding
and
when
you
think
quest
process,
you
know
we're
used
to
building.
Naturally,
the
the
you
know
the
the
front,
the
front-end
servers
on
one
and
the
back-end
servers
from
the
other
end.
We
all
meet
together
at
the
pull
request
kind
of
do
our
end-to-end
testing,
making
sure
all
of
that
works.
That's
a
conversations.
C
Teams
are
very
much
accustomed
to
one
interesting
recommendation
and
and
a
pattern
that
we're
seeing
some
of
the
more
advanced
infrastructure
and
platform
team
taking
on
is
using
automation
to
invoke
that
conversation
by
identifying
issues
together
in
front
of
a
group
as
part
of
the
pr
process.
C
And
if
you
have
centralized
ci
cd
and
you
have
multiple
developers
that
are
kind
of
you
know,
looking
at
those
ci
cd
logs
testing
out
and
to
see
variety
of
ways
to
automate
and
use
variety
of
different
ways
to
build
out
pipelines
to
to
secure
different
types
of
workloads
that,
where
that's,
where
a
conversation
can
be
done
based
on
metrics
and
stats,
because
in
cicd
you
can,
you
can
docker
build.
C
So
you
can
identify
the
vulnerabilities
and
you
can
mimic
a
pre-prod
using
using
dynamic
analysis
or
or
other
types
of
capabilities
that
are
only
available
at
that
stage.
So
these
might
seem
as
two
different
conversations,
but
they
have
one
thing
in
common
where
we're
bringing
in
more
context
in
front
of
more
people
for
them
to
have
the
decision
made
communally
and
not
an
afterthought
once
the
infrastructure
is
already
deployed
right.
B
Yeah,
that's
about
that
ties
and
that
doesn't
matter.
Then
I
mean
you
mentioned:
there's
various
different
various
different
as
source
code
providers,
various
different,
even
git
methodologies
as
to
what
kind
of
workflow
you're
using
there,
but
either
way
that
ties
in.
Doesn't
it
I
mean
that
means
all
of
a
sudden
you're.
Actually,
having
that
conversation,
you're
opening
up
and
you've
got
that
information
to
say
to
make
an
informed
choice,
I
mean,
even
if
that
informed
choice
is
no.
We
need
to
carry
on
with
this.
B
That's
great,
but
at
least
it's
not
happening
in
this
diagram
at
that
very
last
run
time
run
time
phase
where
you
would
then
be
throwing
up
blockers
or
doing
anything.
That's
like
that.
So
that's
that's
really
good!
I
mean
so
that
we've
got
here
and
that
that
segway
paper
that
it's
really
really
good
we've
taken
those
those
graphics
from
it
and
presented
in
a
single
in
a
single
place.
B
C
Yeah,
like
like
everything
I
don't
want
to
oversimplify,
especially
with
with
some
of
the
great
work,
that's
already
being
done
in
cncf
with
regards
to
security,
but
we
do
have
a
couple
of
best
practices
that
that
we
want
to
kind
of
lean
towards
when
we,
when
we
look
forward
into
into
into
implementing
development
by
the
security
development
by
default.
C
I
think
it
goes
back
to
ownership,
and
one
of
the
things
that
that's
interesting
for
me
to
observe
is
to
see
the
fact
that
teams
that
initially
had
devops
functions.
I
think
I'm
not
aware
of
a
company
that
is
cloud
native
and
doesn't
have
a
devops
function,
is
now
starting
to
break
away
into
more
granular
sets
of
of
ownership
with
regards
to
platform
and
infrastructure,
making
sure
that
the
secure
configurations
is
something
that
developers
consume
from
a
secure
location,
the
same
way
as
they
would
consume.
C
Binaries
and
and
use
that
to
build
safe
and
secure
platforms.
Right
and
and
and
I
think,
that's
a
trend
that
we
see
going
forward
and
as
as
far
as
I
can
tell,
we
can
see
infrastructure
team
more
on
the
bottom
part
of
your
screen
focused
on
creating
the
development
in
the
right
runtime
infrastructure,
for
people
to
be
able
to
ship
the
code
as
as
securely
as
possible.
Using
infrastructure,
that's
pre-vetted
and
then
platform
teams
are
developing
the
those
paved
paths
or
paved
roads
for
infrastructure.
C
For
excuse
me
for
for
for
web
developers
and
and
and
other
server
side
developers
to
be
able
to
consume
small
rationalized
bite-sized
pieces
of
platform
for
them
to
naturally
innovate.
B
Guy,
that's
that's
really
good
and
actually
something
you
didn't
know,
because
it's
not
something
we've
ever
spoken
about
that
ownership.
Piece
to
me
is
a
huge
thing.
I
actually,
I
actually
think
that's
a
major
thing.
This
mis
misunderstanding
about
what
ownership
means
and
the
continued
development
nurturing
and
loving
of
whatever
it
is
that
you
have
ownership,
for,
I
think,
there's
a
huge
bit
there,
so
it
was
really
actually
really
good
to
hear
you.
You
talk
about
that
part
now,
where
you
know
we're
here,
there
are
people
listening
to
us.
B
C
Yeah,
so
we
wanted
the
takeaway
part
to
come
as
early
as
possible
in
this
talk,
so
we
took
us
30
minutes,
but
we're
here
now.
I
think
you
know
these
are
universally
biased
towards
my
and
ashley's
personal
experiences,
but
if
we
look
for
a
place
to
start
these
are
these
are
some
of
the
guidelines
that
we've
practiced
internally
in
our
teams
and
are
now
advocating
in
our
current
roles.
C
Let's
start
from
the
left,
let's
shift
to
left
and
start
with
collaboration,
which
I
think
is
is
rudimentary
goes
without
saying,
but
there's
needs
to
be
a
way
to
have
meaningful
technical
discussions
that
happens
between
developers
and
security
and
cloud
is
the
one
that
pushes
us
to
have
those
discussions
without
overhead
for
management
or
architects
good
for
bid
and
really
have
that
as
a
straight
dialogue.
C
I've
mentioned
the
ownership
model
and
I
think
the
the
sig
paper
from
cncf
breaks
out
the
initial
path
for
that
second
actionable
piece
of
advice,
we'll
get
to
this
in
a
quick
demo
in
a
sec,
is
start
with
visibility,
start
with
identifying.
C
You
know
the
the
types
of
configuration
frameworks,
the
types
of
infrastructure
that
your
teams
are
using
and
if
you're
not
aware
of
them,
there's
great
great
tooling
out
there
to
get.
You
started
to
get
create
that
initial
inventory
of
what
people
are
using.
I've
found
that
the
best
way
to
actually
find
out
is
just
talk
to
the
people
themselves
run.
C
C
So
once
you
identify
what
you
want,
what
you
want
to
start
monitoring
is
developer
guardrails,
whether
those
are
in
id
and
or
all
the
way
down
to
runtime
and
we're
big
proponents
of
embedding
those
insights
and
tooling,
as
as
as
early
as
possible
in
the
pipelines,
I've
talked
about
ides
pull
request,
feature
request
scanning
is
fine.
Cicd
are
probably
more
prominent.
Now
get
get
that
visibility
as
far
left
as
you
can.
C
That
will
probably
bring
a
long
ways
to
bringing
the
detection
of
the
solution
and
the
identification
of
the
of
the
problem
into
into
the
rights
of
the
right
into
the
hands
of
the
right
people
and
last,
I
think
what
the
landscape
offers
us
is
the
option
to
choose
between
building
your
you
know,
building
from
scratch,
leaning
on
the
shoulders
of
giants
and
using
open
source
that
this
community
has
cultivated
in
the
last
five
years
and
last
don't
hesitate
to
use
commercial
tooling,
you
can
select
the
best
of
breed.
C
To
put
you
know
the
the
benchmark
on
where
you
want
to
go,
and
then
you
know
close
the
gap
based
on
your
your
personal
preferences
and
and
how
much
of
a
capacity
you're
you're
willing
to
intake
in
terms
of
our
risk
appetite.
B
But
so
I
mean
obviously
I
mean
I'm
wearing
the
t-shirt,
so
that's
where
I
come
from,
but
I
I
look
at
it
as
so.
I
was
a
customer
before
I
before
I
came
over
and
went
to
pilots
and
hours
and
not
going
into
anything
on
the
the
broader
side,
but
my
differentiating
the
value
that
I
added
running
an
openshift
platform
or
bringing
the
financial
services
organization
into
cloud.
Wasn't
the
security
aspect.
It
was
this
essential
part
of
what
we
did,
but
it,
but
it
wasn't
it
wasn't
what
added
value
my
end,
customers
didn't
care.
B
How
that
I'd
written
the
most
amazing
or
engineered
the
best
solution
it
was
it
was
about.
It
was
about
doing
the
right
thing.
So
listen!
We
don't
need
to
go
in.
Obviously
we're
not
we're
not
going
having
the
product
we're
not
trying
to
do
that.
But
can
you
actually
show
us
something
around
this?
I
mean
what
does
that
actually
look
like
and
I'll
stop
sharing.
C
Yeah
and
I'll
I'll
start
sharing.
So
if
you're
not
familiar,
I'm
personally
invested
in
an
open
source
called
checo
ashley.
Do
you
see
my
screen
now.
C
Beautiful,
so
let
me
spell
it
out,
for
you,
so
chekov
is
an
open
source
utility.
One
of
four
that
are
associated
with
hands-on
for
the
past
two
years
and
chekov
is
a
policies
code
frame
framework
that
we've
been
working
on
since
around
2019.
It
was
started
out
by
one
of
my
co-founders,
barack
schuster,
who
has
been
building
and
developing
open
source
software,
since
he
was
probably
14.,
and
he
helped
me
identify
about
two
years
ago.
C
The
fact
that
one
of
the
initial
key
components
to
identifying
misconfigurations
and
being
able
to
resolve
them
in
the
correct
location
is
to
be
able
to
have
a
portable
and
a
lightweight
utility
that
provides
that
visibility
wherever
you
want
to
use
it,
and
that
is,
I
think,
probably
the
most
important
point
for
for
people
that
are
getting
started
start
with
something
that's
portable
and
lightweight.
That
can
teach
you
where
you
want
to
get
started
so
chekhov
I
mentioned
policy
is
code.
C
What
what
does
it
do
it
scans
using
a
a
technique
of
both
study
code
analysis
and
also
a
graph
based
dynamic
analysis
manifests
of
configurations
in
cloud
native
applications.
So
we've
mentioned
terraform
cloud
formation,
azures
resource
manager,
templates
arm
templates
from
the
cloud
native
side.
It
also
does
cdk,
if
you,
if
you're
in
into
that
as
well
serverless
as
well,
but
it
also
goes
into
kubernetes
and
helm
as
well.
C
So
it
really
provides
a
nice
broad
coverage
of
some
of
the
most
popular
configuration
methods
out
there
and
the
nice
thing
about
chekhov
and
if
you've
used,
you
know
naturally
kubernetes
or
terraform
in
the
past
and
docker.
It
follows
that
design
pattern
of
you
can
run
it
locally
on
your
workstation.
It's
actually
a
python
based
tool,
so
you
install
it
in
a
simple.
C
You
know
in
a
simple
pip
command
and
the
nice
thing
about
it
is
you
can
run
it
locally
and
start
to
kick
the
tires
based
on
your
own
own
code,
and
I
have
maybe,
let's
see
one
one
scan
so
check
off
I've
already
installed
it.
I've,
I'm
pointing
it
into
a
directory
that
I
have
locally
that's
storing.
Some
of
my
gcp
manifests
and
I'm
running
the
scan.
So
what
chekhov
will
do
once
I
run
this
scan?
C
C
Configurations
based
in
terraform-
and
it
will
run
them
through
about
it's
almost
900
or
a
thousand
policies
across
all
of
those
seven
or
eight
frameworks
that
I've
mentioned
previously
and
what
it
will
do.
It
will
start
to
flag
varieties
of
configurations
and
identify
if
those
individual
files
are
configured
correctly
or
incorrectly,
so
very,
very
straightforward.
C
I
run
this
locally.
These
are
files.
I
have
local
on
my
on
my
mac
past
past
instances,
look
like
this
and
then
here's
a
failed
instance
not
to
get
too
much
into
the
wheels
of
it,
but
essentially
what
what
we
did
here
is.
We
analyzed
a
resource
block
that
defined,
in
this
case
a
sql
database
in
google
cloud,
and
we
started
to
resolve
all
of
the
different
attributes
in
that
file.
C
So
we
looked
at
the
database
version,
the
region,
the
region
and
the
individual
settings,
and
you
can
see
all
of
these
are
are
set
up
in
in
terraform
code.
Against
most
of
these,
we
have
verification
tests,
most
of
them
aimed
around
security
and
compliance,
but
some
of
them
are
around
also
reliability
and
cost,
and
the
nice
thing
about
them
is
we've
actually
written
less
than
30
percent.
C
Most
of
the
checks
in
in
check
of
today
are
actually
community
community
sourced
we've
had
people
from
some
of
the
biggest
companies
in
the
world
run
check
of
over
the
past
two
years
and
find
you
know
the
craziest
and
anomalous
types
of
findings
you
can
find
and
by
their
journey
into
creating
safe
infrastructure.
C
Chekhov
was
was
their
weapon
of
choice
to
be
able
to
to
start
to
identify
some
of
these
issues.
The
nice
thing
about
it,
I
mentioned
it,
I
run
it
locally.
I
can
test
it.
No
one
needs
to
know
that
I
was
out
of
bounds
by
defining
a
a
bad
bad
certificate
on
on
a
database,
or
I
wasn't
using
the
right
configuration
properties.
B
No
well,
I
have
seen
that
one
part,
because
I
did
do
that.
Install
I
downloaded
and
installed
check
off
myself
and
run
it
against
one
of
my
terraform
templates
and,
like
you
said,
the
nice
thing
was
it
what
actually
having
the
block
to
say
hey.
This
is
what
it
is
and
then
exactly
as
you've
done
it
was
that
thing
of
going
well,
nobody
needs
to
know
what
mistakes
I've
made
locally.
I
can
then
find
out
and
learn
more
about
it
myself.
It's
very
nice.
C
Exactly
so,
we
we
didn't
open
source
and
community
service
only
the
policies,
but
we
also
decided
that
we
want
to
fully
open
source
and
and
publicize
the
documentation
that
went
behind
the
scenes.
So
we
had
our
you
know
our
over
100
maintainers,
probably
more
than
a
thousand
core
users
that
were
constantly
providing
us
valuable
feedback
into
how
to
properly
identify
and
and
fix
issues
based
on
what
they've
been
seeing
in
the
field.
C
So
we
collected
that
information
and
we
logged
it
and-
and
we've
collected,
I
think
one
of
the
most
comprehensive
sets
of
information
data
sets
of
how
to
identify
and
resolve
issues
in
in
in
all
three
cloud
providers.
So
this
is
a
completely
open
resource.
You
can
utilize,
and
the
nice
thing
about
this
is
one
once
you
get.
This
naturally
deployed
into
something
like
a
github
action,
and
this
becomes
crowdsourced
developers
have
a
single
point
to
click,
to
identify
not
only
the
problem
but
also
the
fix.
C
So
we
we
wanted.
We
want
the
chekhov
to
be
something
that
everybody
can
use
and
everybody
can
have
visibility
to.
So
it's
really
built
in
that
really
consistent
design
pattern.
Where
you
can
I'm
going
to
check
of
mine
as
help
to
show
you
some
of
the
variety
of
options
you
have
to
to
be
able
to
deploy
this,
but
you
can
essentially
run
this
on
a
variety
of
scms.
You
can
run
it
as
a
github.
C
Action
is
a
as
a
pipeline
task
in
bitbucket,
negatively
in
your
in
your
gitlab
runner
and
probably
any
type
of
ci
tool.
You
can
imagine
so
really
easily
exportable
into
all
of
those
popular
ci
platforms
encapsulated
into
a
single
docker
can
be
run
essentially
anywhere
and
provide
tons
of
value
as
part
of
a
ci
cd
run,
especially
for
a
smaller
team.
C
That's
looking
to
to
get
get
that
insight
before
issues
are
deployed
into
production,
you
can
see
we
have
the
varieties
of
of
be
able
to
run
a
run,
a
full
quiet
session,
with
the
ability
to
skip
individual
checks
or
to
run
just
specific
checks.
C
We've
recently
introduced
the
ability
to
do
image,
scanning,
natively
and
variety
of
ways
to
kind
of
fix
and
and
instantly
mix
and
match,
based
on
your
individual
preferences,
the
the
overwhelmingly
popular
usage
pattern
would
usually
be
someone
who's,
probably
listening
in
on
this
webinar
pip
installs
checkoff
identifies
that
it
gives
them
value
locally
and
then
uses
some
of
these
advanced
options
to
identify
the
best
ways
to
to
use
it
in
their
cict
pipelines.
B
So
that
and
then
that's
the
thing
so
you
by
by
having
that
help
that
the
help
format
there
to
show
us,
I
mean
even
even
me
as
a
luddite.
I
can
see
exactly
how
I
could
make
use
of
that
as
calling
webhook
to
call
check
off
to
have
that
result,
and
even
if
then,
we
agreed
we're
gonna,
we're
gonna
that
whatever
the
failure
was
actually
it's
acceptable,
because
for
whatever
reason
I've
decided
my
business
risk
is
such
that
this
is
okay.
B
C
Really
cool
yeah,
one
thing
I
a
last
one
thing
I
want
to
show
you.
I
know
we
we're
kind
of
running
out
of
time.
We've
done
one
last
thing,
which
is
to
mount
chekov
on
a
very
popular
code,
editor
visual
studio
code.
C
You
might
be
familiar
with
it's
also
part
of
part
of
a
a
very
recent
launch
coming
out
of
github
around
code
spaces
if
you're
familiar
with,
but
if
you're
a
vs
code
user,
one
of
the
ways
to
infiltrate
and
to
get
into
into
id
and
to
make
sure
some
of
those
valuable
insights
arrive
into
the
desktops
of
developers-
and
you
everywhere
is
through
this
through
this
extension.
That's
that's
also
fully
open
source
and
accessible
to
our
community
and
what
this
essentially
does
it.
C
It
mounts
on
top
of
a
vs
on
a
vs
code,
that's
running
and
analyzing
already
analyzing
your
hard
written
infrastructure
as
code
and
it
kind
of
annotates
the
problems
as
as
you
compose,
as
you
run
the
code.
So
in
this
case
I
have
a
couple
of
my
managed
kubernetes
files
here
on
hand.
You
can
see.
C
I
have
an
azure
kubernetes
file
in
an
amazon
one
and
a
gke
and
a
google
one
as
well,
and
once
I
have
the
extension
wired
here
on
the
back
end
you'll
see
that
I
have
check
off
scanning
here
on
the
on
my
bottom
pane
and
what
chekhov
will
essentially
do
for
you
as
a
developer.
Even
if
you
have
you
know
zero
tolerance
to
security,
people
reviewing
your
code
and
telling
you
what
you
need
to
be
doing.
It's
going
to
inject
those
insights
and
those
over
almost
a
thousand
policies.
C
It
will
do
so
by
annotating
the
individual
resources
listing
out
the
variety
of
problems
that
may
have
been
found
in
a
much
more
pleasant
way
inside
those
code
manifests,
and
it
will
even
go
as
far
as
giving
you
the
ability
to
single
click,
fix
or
generate
a
skip
comment
for
select
instances
of
configuration.
C
So
you
can
use
the
drop
down
point
at
your
resource
of
choosing
and
then
with
a
single
click
of
a
fix.
Add
a
missing
attribute,
for
example,
to
enable
logging
to
disable
the
cube
dashboard
and
just
to
make
sure
that
your
settings
are
aligned
correctly.
C
If
you're
interested
on
where
these
misconfigured
files
came
from,
they
actually
came
from
another
open
source
project
by
bridge
crew,
which
is
terra
goat,
which
will
give
you
the
opportunity
to
kind
of
use
a
vulnerable
by
design
set
of
files
to
train
and
educate
yourself
about
how
misconfigured
code
might
look
like
and
use
something
like
the
checkoff
plugin
to
be
able
to
to
analyze
and
to
identify
the
best
ways
to
fix
or
resolve
the
variety
of
issues
that
can
be
found
in
in
a
popular
manifest
like
like
the
public
aks
cluster.
B
C
All
of
all
bridge
crew,
open
source
is
apache2
license,
so
you
can
take
it
do
whatever
you
want
with
it,
we'll
be
happy
to
to
get
contribution
back
and
and
to
let
them.
You
know,
let
us
know
how
it
works.
C
Yeah,
so
I
think
that's
that's
my
portion.
We
can
start
wrapping
up.
B
I
think
so
I
think
I
think
we've
I've
got
a
final
slide
just
to
see
us
out,
but
actually
at
this
point
this
is
when
everybody
should
be
typing
lots
of
questions
in
there.
I
see
that
we've
had
one
coming
already,
but
this
is
your
opportunity,
while
I
share
out
my
screen
and
get
away
from
that
last
slide.
B
So
let's
recap
this,
while
everyone's
thinking
of
their
very
difficult
questions
for
you,
hopefully
what
what's
the
benefits
to
all
of
this
we've
described,
we
went
through
a
nice
bit
of
us
chatting,
we've
seen
some
really
cool
stuff.
Thank
you
because
that
is
the
first
time
I've
seen
a
lot
of
that
cool
stuff
and
now,
what's
the
benefits
guy.
C
Yeah,
so
maybe,
let's
quickly
frame
this
approach
as
people
are
typing
on
typing
in
their
questions,
we've
singled
out
policy
as
code
in
in
this
quick
demo
and
we're
we're
kind
of
playing
through
to
that
to
that
end
goal.
C
But
if
you
think
of
policies
code,
the
nice
thing
about
these
standalone
utilities,
they
give
you
the
opportunity
to
test
it
yourself,
download
locally,
run
it
against
your
actual
code,
and
if
you
don't
want
to,
you,
can
take
something
like
an
extension
that
gives
you
some
of
that
insight
directly
into
your
into
your
coding
experience.
C
Why
is
this
amazingly
awesome
for
people
that
are
doing
cloud
native
development?
It's
powered
by
a
community
just
like
all
of
the
other
tools
that
we
love
using
like
kubernetes,
terraform
and
others,
and
it
creates
a
repeatable
process
for
you.
You
don't
need
to
run
that
cli
over
and
over
again,
you
put
it
once
into
your
into
your
ci
process.
You
deploy
this
extension
once
into
your
vs
code
and
you're
suddenly
protected,
and
your
code
gets
so
much
better
than
it
was
before.
C
Second
biggest
benefit,
I
see,
is
the
fact
that
you
are
conscious
about
the
fact
that
there's
going
to
be
issues
that
you're
not
going
to
be
able
to
fix,
but
it's
going
to
get
you
much
much
faster
to
fix
the
ones
that
do
have
a
fix
and,
and
we
we
can
spend
you
know
eternity
creating
bills
of
of
open
source
materials
that
we
can't
rip
out.
C
We
can
create
spreadsheets
on
spread
on
top
of
spreadsheets
of
all
of
the
vulnerable
packages
that
we
might
have
buried
inside
our
package,
json
in
a
repo,
and
we
can't
replace
because
it's
running
our
code,
but
if
we
start
by
focusing
on
the
configurations
that
we
can
literally
change
by
adding
one
or
two
lines
of
code
that
will
just
bring
you
so
much
faster
into
into
much
more
secure
and
robust
by
default
infrastructure.
C
Cloud
infrastructure
third
benefit
is
that
when
we
introduce
some
of
these
tooling
into
areas
like
our
ide,
our
pull
request
process
we're
making
sure
that
they
don't
arrive
into
runtime.
If
it's
in
runtime.
That
means
friction.
That
means
an
application
needs
to
be
changed
to
be
altered,
which
needs
to
be
shut
down
in
order
for
us
to
make
it
slightly
more
secure
that
some
something
that
most
business
don't
have
a
lot
of
tolerance
to.
B
So
and
to
me,
that's
the
that's,
the
big
one
and
everyone
who's
listening
can
can
breathe
a
sigh
of
relief.
You
don't
need
to
listen
to
this
crazy
scotsman
anymore,
but
that's
the
big
one
for
me
is
that
that
the
friction
there's
one
thing
trying
to
present
something
to
go
into
production
and
not
knowing
that
you've
got
these
holes
or
that
they're
going
to
be
picked
up
or
someone's
going
to
shout
about
them,
but
actually
it
eases
a
lot
more.
B
If
you
yes
well,
if
I'm
aware
fully
of
all
the
issues-
and
this
is
the
only
one-
that's
a
security
one
and
here's
why
that's
necessary
or
here's
the
risk
associated
with
it.
So
I
I
find
that
that
was
really
good
guy.
Thank
you
very
very
much.
I
really
do
I
love
talking
to
you.
So
it's
really
good
and
thank
you
for
letting
me
bully
you
at
the
start
and
I've
not
seen
that
demos
I
really
enjoyed
seeing
that
demo.
Thank
you.
B
I
do
see
that
we've
got
a
question
in
there:
lots
of
people
saying
hello,
which
is
nice,
hello,
everybody.
There
is
another
question:
I'm
going
to
read
it
out,
because
then
you
need
to
answer
it
guy.
If
I
find
issues
using
chekhov
and
I
don't
own
the
template,
what's
the
best
way
to
get
the
other
person
to
make
the
fix.
C
Yeah
definitely
definitely
a
good
question.
That's
going
to
be
on
your
mind
if
you're
going
to
try
to
implement
chekhov,
so
the
world
kind
of
splits
into
two
program
spaces,
one
is
going
to
be
the
infrastructure
that
you
have
composed
and
owned,
and
the
other
is
going
to
be
the
public
modules
and
artifacts
that
you've
downloaded
from
a
hopefully
a
secure
location
from
the
public
internet.
The
first
cluster,
our
first
group
is,
is
very,
very
easy
right.
So
this
is
infrastructure
that
I
compose
I
own.
I
can
fix
them
directly.
C
I
don't
need
to
ask
anyone
should
be
pretty
straightforward.
Nice
thing
about
chekov
is
that
it's
fully
aware
of
encapsulated
modules
and
variables
that
are
used
locally.
So,
if
you
fix,
if
it
identifies
a
problem,
you'll
be
able
to
identify
it
all
the
way
into
the
variable
that
that
it
originated
from
that.
C
Second
cluster
is
a
problem
and
that's
where
platform
and
for
infrastructure
teams
use
checkover
on
a
day-to-day
basis
to
identify
the
templates,
the
modules
that
are
getting
used
by
by
teams
that
are
not
vetted
beforehand,
and
that's
that's
the
group
where
we
we
need.
We
need
better
visibility
on
as
an
industry
and
and
and
one
of
the
one
of
the
ways
to
make
that
vetting
and
to
make
those
changes
is
to
contribute
back.
C
If
you,
if
you're,
using
a
publicly
accessible
module
from
something
like
the
terraform
registry
or
from
our
defect
hub,
you
know,
step
up
and
help
us
configure
secure
defaults
to
those
and
help
us
bump
up
those.
I
think
it
was
43
47
for
most
of
them
and
make
make
sure
more
more
and
more
public
configurations
are
in
par
with
what
we
want.
Our
private
configurations
to
be
to
be
adhering
to.
B
Well,
and
then,
in
which
case
I'll
I'll
add
on
to
that,
from
from
the
work
that
I've
done
along
with
people
in
cncf
and
work
with
cncf,
it's
the
same
kind
of
thing
don't
feel
put
off.
If
you
want
to
contribute
back
that
you
you
need
to
just
do
code,
it
doesn't
have
to
be
just
code.
The
cncf
is
the
reason
why
it's
so
successful
is
because
of
this
community,
and
so
this
community
is
about.
You
can
contribute
back
in
in
many
different
ways.
B
You
can
contribute
back
with
time,
documentation
holding
meet-ups
being
involved
coming
along
to
things
like
this.
So
yes,
absolutely
everything
that
guy
said,
but
also,
if,
if
you,
if
you're
doing
something,
you
see
something
just
just
get
involved
and
be
part
of
it,
that
was
really
exciting.
Thank
you
very
much.
Actually,
looking
looking
at
time,
I
don't
see
any
other
questions
coming
through
on
chat,
so
I
am
going
to
put
you
on
the
spot
guy.
B
C
The
easy
one
I
think
the
most
inspiring
thing
has
been
to
see:
teams
and
people
from
teams
that
we
looked
up
looked
upon
three
years
ago,
when
we
wanted
to
learn
how
some
of
the
strongest
and
and
most
talented
teams
in
cloud
native
are,
building
and
and
innovating
through
the
community.
Seeing
them
contribute
back
to
chekhov.
C
So
you
can
recently
added
a
page
to
recognize
some
of
those
rock
stars
that
are
bringing
in
some
of
that
world-class
knowledge
and
talent
into
chekhov
and-
and
I
think,
that's
been
especially
especially
rewarding
to
see
to
be
able
to
learn
through
the
experiences
of
you
know:
people
who
are
operating
some
of
the
most
complex
systems
in
the
world
through
the
lens
of
of
their
code.
B
Yeah,
I
get
that
that's
so
that's
really
good
and
thanks
for
letting
me
put
you
on
the
spot
and
answering
that
really
well
yeah.
I
absolutely
couldn't
agree
more
well,
listen,
everybody!
I
know
that
sometimes
in
in
forums
like
this,
it
can
be
difficult
to
ask
questions
because
it
it
you
know,
that's
the
way
of
the
world,
it's
it
can
be
obtrusive.
Even
when
we
were
in
person.
It
was
always
difficult
in
a
forum
like
this
to
get
people
to
ask
questions
oftentimes,
it
was
afterwards
people
would
come
up
and
say
hey.
B
I
just
wanted
to
know
about
such
and
such
so
listen.
You
can
reach
out
to
us.
Obviously
palo
alto
networks,
we're
obviously
happy
to
hear
from
you,
I'm
I'm
award
at
paloutanetworks.com,
guys
guys
and
call
it
a
guy
at
palo,
alto
networks.com.
So
that's
the
g.
Instead
of
the
set
of
the
guy
get
in
touch,
please
reach
out
anything.
We
can
do
to
help
with
that.
That's
why
we
do
this
right,
so
guy
I'll
finish
off.
Thank
you
for
your
time.
You
did
the
bulk
of
the
talking
and
made
me
look
good.
A
Thank
you
both
so
much
and
thank
you
everyone
for
joining
us.
If
there
are
no
other
questions,
we
will
go
ahead
and
wrap
this
up
and,
like
I
said,
the
decks
and
the
recording
will
be
online
later
today.
So
keep
an
eye
out
for
that,
and
thank
you
both
so
so
much
and
have
a
great
day.