►
From YouTube: DevSecOps Lunch and Learn (East)
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
Hello,
everyone
and
thanks
for
attending
today's
virtual
event,
my
name
is
tam
and
I'll,
be
your
moderator.
For
today
we
have
michael
ionati
he's
our
regional
sales
manager
for
the
east
coast,
as
well
as
central
he'll,
be
giving
an
overview,
and
we
also
have
chris
porter
on
he's.
Our
director
of
solutions,
engineering
he'll
be
giving
the
live
demo.
A
A
A
B
Great,
thank
you
tam
and
yeah
guys,
so
just
want
to
walk
you
through
really
quickly
an
overview
of
stack
rocks
where
we
fit
in
the
market
and
sort
of
begin
to
tell
you
about
what
makes
us
unique,
we'll
not
bore
you
in
powerpoint,
very
long,
we'll
pass
it
over
to
chris
here
shortly
to
show
you
the
good
stuff
in
the
actual
demo
and
the
gui,
but
you
know
from
a
high
level
in
terms
of
where
did
this
fit
in
the
market.
The
answer
is
very
much
within
this
container
kubernetes
world
right.
B
So
you
know
five
years
ago,
docker
came
to
market
with
and
containerization
started
to
get
really
popular
people
got
excited
about
the
scalability
and
flexibility
that
come
with
containers.
What
we
think
people
realize
really
quickly
was
that
containers
by
themselves
are
very
difficult
to
manage
right.
They
don't
have
many
inherent
controls,
and
so
we
think
more
recently,
the
shift
of
focus
has
been
from
just
containers
towards
containers
running
with
proper
orchestration
and
for
us,
what's
important
to
know
about
stack
rocks
is
proper
orchestration
means
kubernetes.
B
We
are
100
focused
on
containers
running
in
kubernetes
environments.
Now
that
means
kubernetes
in
any
of
its
distributions
right
any
of
the
managed
providers
like
amazon,
eks,
azure,
aks
gke.
It
means
things
like
openshift
for
red
hat.
It
means
certainly
kubernetes
on-prem,
but
but
focus
on
kubernetes
and
delivering
security
through
the
orchestrator.
B
That's
what
we
think
makes
the
solution,
unique
and
and
valuable
is
the
way
that
we
are
delivering
security
as
code.
So
these
are
the
use
cases
that
we
address
these.
These
eight
items
with
check
marks
that
you
see
here.
These
are
the
reasons
that
anyone
is
going
to
invest
in
the
stack
rocks
platform
again
same
set
of
use
cases
that
you'll
talk
about
with
a
bunch
of
other
container
security
tools.
B
But
what
we
think
is
interesting
and
what
chris
will
spend
time
walking
you
through
today
is
how
we
approach
these
things
differently
from
this
kubernetes,
this
kubernetes
approach,
so
the
other
thing
that
folks
typically
are
is
very
important
to
them
at
the
onset
when
they
see
a
tool
like
this
is
around
integrations
into
the
res
rest
of
their
devops
pipeline
tooling.
So
you
see
some
examples
of
other
tools
that
we
integrate
with
at
the
bottom
of
your
screen.
One
thing
to
note:
that's
not
a
complete
list!
B
There's
there's
other
integrations
that
I'm
sure
chris
will
show
you
in
the
product.
But
the
important
thing
to
know
is
we.
We
come
with
a
native
web
hook,
so
anything
that
exposes
apis
is
typically
very
easy
to
tie
into
so
very
very
little
in
terms
of
limits
for
for
integrations
that
you
can.
You
can
have
with
this
and
other
tools
always
important
to
our
customers,
and
these
integrations
are
customer
driven.
B
And
and
yeah
guys,
just
you
know
one
more
slide
to
kind
of
highlight
why
we
think
this
kubernetes
native
approach
is
as
advantageous
and
it's
not
to
say
anything
negative
about
other
container
focused
tools
out
there
right.
There
are
a
number
of
tools
that
came
to
market
four
or
five
years
ago,
with
docker
to
secure
containers
right
and
at
the
time
they
had
to
be
able
to
secure
containers
running
across
kubernetes
and
mesosphere,
and
nomad
and
docker
swarm
all
of
these
different
platforms.
B
What
we
think
we
have
this
advantage
is
we
came
to
market
with
this
product
really
at
the
beginning
of
2019,
and
so
that
gave
us
some
extra
time
to
see
that
90
percent
of
the
market
is
moving
towards
kubernetes.
It
has
evolved
to
become
the
the
orchestration
platform
of
choice
for
just
about
everyone
else
out
there.
So
we
said
we
want
to
build
a
product
which
is
not
focused
on
containers,
but
it's
focused
on
deployments,
pods
namespaces,
the
constructs
that
we
think
matter
more
in
a
kubernetes
world.
B
So
a
few
you
know
a
few
advantages
that
I
I
would
encourage
you
to
look
for,
as
chris
shows
you
the
tool
around
the
ideas
of
richer
context.
Right.
Can
we
help
you
prioritize
risk
based
on
our
understanding
of
your
overall
kubernetes
environment
and
an
example.
Here
is
guys,
you
know
everything
everybody
you
know
when
you
move
to
a
container
environment,
you
want
to
worry
about
scanning.
Your
containers
for
vulnerabilities
and
and
cve
scores
right
prioritize.
That
way,
we
think
there's
other
things
that
should
influence
this
right.
B
We
think
you
should
care
more
about
a
vulnerability
depending
upon
whether
it's
in
production
or
or
tests,
and
if
the
container
has
access
to
the
internet
and
depending
upon
how
the
container
has
been
privileged,
based
on
a
bunch
of
other
factors
that
we
understand
from
kubernetes
and
help
use
to
prioritize
your
risk
in
your
environment.
So
you
understand
where
to
start
next
is
around
this
idea
of
native
enforcement
and
and
really
what
we're
thinking
about
there
is.
C
B
C
You
this
is
a
software
product
and
stackrocks
provides
a
software
as
a
kubernetes
application,
so
it
runs
in
your
clusters.
This
means
that
there's
no
external
access
necessary
stack,
rocks.
Folks,
don't
have
access
to
your
data,
so
it
runs
entirely
in
your
premise,
wherever
that
might
be
in
the
cloud
in
a
physical
data
center
hybrid
environments,
and
we
have
the
product
broken
up
so
that
you
have
a
single
pane
of
glass
like
a
single
place
to
do
all
of
the
policy
controls
to
do
all
of
the
monitoring
and
the
integration
with
third-party
systems.
C
We're
going
to
be
looking
at
that.
We
call
central
in
the
demo
here,
so
central
would
integrate
with
build
tools
like
jenkins
registries,
like
cloud
hosted
or
local
image
registries,
and
then
the
sensor
and
the
collector
run
in
your
clusters,
and
these
are
very
lightweight.
One
of
the
reasons
that
the
product
can
be
so
lightweight
is,
as
mike
said,
we're
gathering
information,
but
then
we're
using
kubernetes
to
do
a
lot
of
the
enforcement
you're
going
to
see
a
lot
of
that
message
here.
C
What
sacrifice
is
trying
to
do
is
program
kubernetes
to
help
meet
security
goals
in
your
organization.
You
know.
We
think
that
the
focus
of
kubernetes
has
been
on
management
and
capabilities
like
high
availability
and
quick
time
to
recover
from
errors.
We
also
believe
that
it
can
be
used
to
shape
the
the
security
landscape
here
as
well,
so
what's
acceptable
and
what's
not
acceptable,
we'll
see
how
we
use
kubernetes
for
those
native
features
that
could
be
that
can
be
used
towards
towards
your
security
goals.
B
Sorry
sure
do
you
want
to
put
back
there?
Yep
sorry,
no
need
to
spend
a
lot
of
time
here,
guys
right.
This
is
the
nascar
slide
to
show
you.
You
know
some
of
our
referenceable
customers.
You
know,
we've
got
some
pretty
large
deployments,
folks
that
are
running
this
across
thousands
of
nodes
at
places
like
ibm
and
sap.
B
We
have
a
lot
of
federal
customers,
so
intelligence
agencies,
things
of
that
sort.
That
use
the
platform
that
I
know
very
little
about
given
ndas
and
then
a
lot
of
you
know
what
I
would
call
cloud
native
companies,
companies
that
were
kind
of
born
in
containers
and
kubernetes
or
you
know,
started
using
those
platforms
a
long
time
ago
for
whom
this,
this
kubernetes
native
approach
just
makes
a
lot
of
sense.
A
A
C
Great
thank
you.
I
want
to
switch
over
here
to
a
live
environment
and
won't
be
sharing
the
slides
here
anymore
bring
this
up.
So
I
thank
everybody
for
joining
us
today.
Hopefully,
we
will
be
able
to
show
you
some
things
here
that
I
think
are
are
pretty
interesting.
They
should
be
able
to
get
something
out
of
this
you'll
see
our
suggestions
here,
you
can
see
more
on
our
website,
for
you
know
how
we
approach
security
from
a
from
a
cloud
native
way.
C
Hopefully
you
guys
will
we'll
see
some
of
the
the
recommendations
that
we
make
and
make
use
of
them
here
now.
Obviously,
we're
talking
about
the
stack
rocks
product
here,
and
this
is
the
web
interface
for
it,
but
you
know
the
the
kind
of
principles
that
we're
talking
about
in
security
that
accomplish
the
traditional
security
goals,
but
at
the
same
time
preserve
the
value
of
what
kubernetes
offers.
C
You,
I
think,
is
our
goal
right
now,
a
lot
of
the
things
that
we
would
recommend,
like
you
know,
knowing
where
your
images
come
from
and
how
they're
being
deployed
understanding
the
capabilities
of
the
kubernetes
platform,
understanding
where
the
defaults
in
kubernetes
and
docker
images
are
and
which
of
those
defaults,
are
good
for
security
and
which
ones
are
bad.
Those
are
general
lessons
that
you
can
apply
to
your
environment.
You
know
starting
today,
but
this
is
the
stack
rock
software
it's
running
in
a
service
inside
of
my
own
cluster.
C
I've
got
actually
two
clusters
here
that
I'm
monitoring.
So
this
is
a
relatively
small
demo
environment,
but
this
is
live
right
now.
So
when
you
look
at
the
deployments-
and
you
see
the
images
you're
actually
running
in
a
cluster
out
on
the
internet
today
and
they're
they're
being
monitored
by
the
stack
rock
software
now
we
talk
about.
C
You
know:
security
in
a
devops
world
right
if
you're
adopting
kubernetes,
we
assume
that
you're
going
to
adopt
this
for
the
ability
of
kubernetes
to
enable
a
devops
sort
of
life
cycle
for
your
applications
right
the
advantages
of
devops.
You
know
I
don't
have
to
go
into,
but
agility
the
ability
to
to
rapidly
shift
to
changing
requirements
to
being
able
to
recover
from
failure
and
experiment
at
low
cost,
and
so
all
that
is
embodied
by
kubernetes
and
security
is
traditionally
looked
at
as
upon
as
something
that
restricts
developers.
C
In
fact,
we
joke
that
developers
really
don't
like
security
products,
but
we're
trying
to
make
one
here
that
will
make
both
sides
happy.
Let's
say,
give
the
developers
that
flexibility
in
fact
help
them
enable
their
organizations
to
use
kubernetes
and
gain
this
flexibility,
but
at
the
same
time
reassuring
the
security
audience
that
hey,
there's
oversight.
Here
I
can
meet
compliance
requirements.
I
can
understand
risk
and
I
can
fend
off
attackers
that
might
try
to.
You
know
intrude
on
my
on
my
running
applications.
C
C
But
I
also
like
to
point
out
that
you
know
the
kind
of
the
preference
from
us
here
at
stack
rocks
is
that
we
integrate
the
stack
rocks
products
with
the
development
tools,
so
just
briefly
get
ahead
of
those
questions
there.
This
works
with
the
jenkins
plug-in
that
we
have
it
works
with
any
ci
cd
tool.
C
So
if
you're
using
azure
devops
gitlab
github
actions
concourse
you
name
it,
we've
done
work
to
be
able
to
create
things
like
this,
like
issues
highlighted
for
each
individual
developer
in
their
preferred
interface,
you'll
also
see
in
the
end
we
talk
about
integrations
and
notifications.
We
support
chat,
ops
tools,
like
microsoft
teams
or
slack
bug
tracking
tools
like
jira.
So
we
really
think
that
one
of
the
advantages
of
doing
you
know
approaching
the
security
problem
from
this
way
is
to
do
it
natively
with
those
tools.
C
Now
what
we're
looking
at
here
is
one
of
the
major
use
cases
it's
providing
visibility
and
understanding
of
vulnerability.
Data
in
my
environment
and
vulnerability
data
is
one
of
those
things
that
you
know.
Every
container
security
product
should
have
this
most
environments
have
something
like
this
available.
In
fact,
increasingly,
we
see
the
vulnerability
management.
The
part
where
I
go
and
and
look
up
the
the
images
and
the
layers
and
break
it
down
into
components
and
show
you
this
list
of
you
know.
C
Vulnerabilities
is
part
of
a
lot
of
the
platforms
too
so
openshift
and
the
cloud
providers
have
this.
So
the
question
really
is
not
like
whether
or
not
you
have
this,
but
how
you're
making
use
of
it.
Now
we
feel
like
there's
two
big
problems
with
vulnerability
management.
One
is
that
it's,
it's
often
noisy,
there's
a
lot
of
data
here
and
a
lot
of
vulnerabilities
present
in
most
things,
so
we
think
it's
really
important
to
understand.
You
know
where
did
this
come
from
and,
and
you
know
how
impactful
is
it
that's?
C
The
other
challenge
there
is
is
knowing
exactly
how
impactful
these
are
and
we're
going
to
talk
a
little
bit
about
how
we're
broadening
the
view
of
security
in
images
and
kubernetes
to
get
beyond
just
simple
vulnerability
management,
but
if
you're
looking
for
a
solution
that
provides
easy
navigation,
deep
levels
of
information
about
vulnerabilities
and
even
you
know,
sort
of
assign
problems
to
vulnerability
management.
Things
like
when
were
my
images
dated
and
where
did
they
come
from?
C
We
can
provide
all
that
information
here
and
controls
to
you
know
to
stop
people
from
doing,
for
example,
things
like
this,
bringing
in
images
that
come
from
some
unknown
source
or
some
external
source,
and
not
touching
them
again.
In
fact,
image
freshness
is
one
of
the
things
that
we
can
point
to
as
being
critical
for
any
organization.
C
So
as
we
look
through
my
images
here,
you
can
see
that
the
ones
with
really
bad
results
right-
lots
of
fixable
vulnerabilities
in
them
haven't
been
updated.
For
you
know
two
or
more
years.
This
is
one
of
the
biggest
recommendations
that
we
can
make
understand
where
your
images
are
coming
from
right.
The
development
teams
love
being
able
to
go
and
pull
these
down
from
docker
hub,
but
they're
often
abandoned
where
right.
C
C
You
need
to
keep
the
packages
in
there
updated
by
either.
You
know
bringing
that
in
again,
building
those
images
again
or
or,
of
course,
just
providing
the
updates
from
the
from
the
package
providers
there.
So
the
go
focus
on
these
fixable
vulnerabilities
is
is
important
right.
We
want
teams
to
be
able
to
to
look
at
these
severely
scored
vulnerabilities,
understand
the
impact
and
fix
them
when
there
are
fixes
provided,
but
to
get
past
some
of
these
issues
with
the
noise
and
the
constant
updates
and
understanding
like
where
they're
in
use.
C
We
we're
going
to
point
to
a
different
topic
here,
and
so
the
broader
concept
of
risk
in
your
applications
now
takes
the
concept
of
container
security
and
flips
it
around.
Now
we're
looking
at
things
from
the
top
down
here
from
kubernetes
perspective
and
we're
looking
at
instead
of
images
we're
looking
at
the
the
applications
running
in
my
clusters
in
the
various
namespaces.
C
C
So
we
make
the
distinction
here,
but
a
really
simple
example
of
risk
is
this
that
you
know
when
I
have
services
that
are
running
inside
of
kubernetes
if
they're
not
exposed
outside
of
the
cluster,
they
really
can't
be
reached
by
anyone
on
the
network
outside
of
the
cluster.
The
ones
that
are
exposed
called
reachability
means
that
I
am
much
more
likely
to
see
an
attempt
against
that
particular
vulnerability.
C
Also
things
like
privilege,
levels,
network,
port
exposure,
resource
requests
and
limits.
These
are
attributes
of
the
deployment
and
you'll
see
stack,
rocks
talk.
You
know
talk
quite
a
bit
about
this,
that
it's
not
just
the
build
of
the
image.
It's
the
deployment
configuration
that
goes
into
kubernetes.
That
becomes
important,
so
you
know:
are
you
providing
a
cpu
or
memory
limit
right?
This
is
a
medium
severity
item,
but
it
means
that,
if
an
attacker
compromises,
a
running
container
kubernetes
can
limit
the
amount
of
cpu
and
memory
given
to
that
right.
This
would
foil
attacks
against.
C
We
can
also
see
that
there's
certain
information
here,
like
environment
variables,
that
contain
secret
information.
This
is
workflow
errors.
We
can
also
see
that
other
types
of
software,
like
what
we
call
components
that
are
useful
for
attackers,
are
present
on
this
particular
deployment
here,
which
means
that
an
attacker
who
gets
a
foothold,
maybe
they
compromise
a
minor
vulnerability,
one
that
you
know
doesn't
allow
them
to
get
root
level
access,
but
other
tools
that
are
present
on
the
container.
C
Lastly,
we're
also
looking
at
things
like
how's,
your
kubernetes,
our
back
setup
for
this
kind
of
a
subtle
issue,
and
often
one
that
teams
aren't
often
aware
that
kubernetes
has
a
built-in
role-based
access
control
system
and,
like
most
systems
with
different
levels
of
privilege,
organizations
tend
to
start
running
things
with
higher
levels
of
privilege
than
they
need.
In
fact,
even
the
defaults
in
some
cases
are
too
high,
as
we've
seen.
Some
exploits
against
kubernetes
clusters
involving
role-based
access
control
for,
like
even
unauthenticated
users.
C
A
C
Great
question,
so
we
provide
a
ci
cicd
tools
that
either
integrate
directly
using
our
plugins.
So
if
you
look
up
on
the
thejenkins.io
site,
you'll
see
the
stackrock's
image
security
plugin
for
examining
images
for
vulnerability
data,
so
the
same
image
that
we
data
we
saw
here
in
the
vulnerability
management,
page
cves
and
other
data
will
be
presented
directly
in
the
build.
C
The
idea
here
is
that,
at
the
end
of
your
build
as
you're
composing,
you
know
docker
image
files
pushing
them
into
a
registry,
we'll
evaluate
the
those
for
for
vulnerabilities
and
focusing
again
on
the
fixable
vulnerabilities
right.
We
don't
really
think
that
it's
going
to
be
possible
practical
for
most
developers
to
go
fix.
C
So,
aside
from
vulnerabilities,
we
can
also
grab
the
fact
that
you
know
folks
are
using
privilege
mode,
and
you
know
folks
are
using
things
like
you
know
like
have
having
curl
present
in
the
image
so
going
beyond.
Just
the
the
vulnerability
data
to
how
is
this
deployed?
How
was
it
created?
You
know
somebody's
attempting
to
deploy
a
you
know,
an
application
with
the
cluster
admin
level,
the
privilege
in
the
cluster
we
can.
C
We
can
identify
that
at
build
time
and
again
push
teams
towards
the
right
solution,
we're
going
to
see
some
details
in
a
little
bit
about
what
we
mean
by
these
policies
and
why
they're,
important
and
and
what
teams
can
do
about
it.
So
if
these
things
all
look
a
little
bit
mysterious,
we'll
we'll
jump
into
that
a
little
bit,
you
know
shortly.
A
C
C
So
what
we
can
do
is
instrument
of
this,
so
the
kubernetes
cluster
here
from
the
kubernetes
cluster,
I
can
determine
what
images
are
in
use
and
it
will
scan
those
images
at
that
time,
but
we
keep
this
information
up
to
date,
and
this
is
one
of
those
important
things
where
you
know.
If
I
run
a
you
know
a
deployment
here
and
I
leave
it
running
for
days.
C
You
know
a
vulnerability
could
be
discovered.
Who
knows
tonight
right,
and
I
want
to
be
able
to
find
that
vulnerability
in
here
and
I
can
search
for
it,
and
this
is
one
of
the
challenging
problems
about
vulnerability
management.
You
know
you
scan
it
once
at
the
end
of
your
build
it
gets
put
in
the
registry,
and
at
that
point
it
you
know
it
gets
used
forever
right
teams
don't
go
back
and
revise
them.
Then
they're
not
picking
up
those
vulnerability
scans,
and
so
we
can
understand
when
hey
a
new
vulnerability
was
published
last
night.
C
Let's
just
pick
one
here
at
random.
This
is
a
live
environment
and
you
know
when
I
see
those
vulnerabilities
that
are
present
in
my
environment
here,
I
can
rank
them
right
according
to
their
their
priority
score.
So
looking
at
you
know
new
2020
vulnerabilities
here
I
can
see
that
I
do
have
you
know
a
bunch
of
my
my
running
deployments
impacted
by
that-
and
this
is
where
this
risk
makes
a
great
deal
of
sense.
The
risk
can
tell
me
where
do
I
have
to
to
start
like?
C
Where
do
I
need
to
fix
this
this
vulnerability
and
are
there
conditions
that
would
cause
me
to
you
know
to
to
need
to
take
action
like
take
things
offline,
get
people
out
of
bed.
You
know,
raise
the
alarms
and
get
applications
patched.
So
this
will
give
you
you
know
an
order
of
operations
here.
This
you
know
old
vulnerability
here
is
present
in
four
of
my
deployments,
but
it's
really
this
one
here
where
it
looks
like
I've
got
a
problem
and
it's
an
exposed
service
that
needs
to
be
addressed
right
now.
C
Now,
if
you
like,
the
vulnerability
data
can
come
from
anywhere.
In
fact
here
in
the
integrations,
we
support
a
number
of
third-party
open
source,
cloud-based
or
commercial
vulnerability.
Scanners.
Stackrock's
purview
here
is
really
only
kubernetes
clusters
and
images,
and
a
lot
of
our
customers
already
have
a
solution
that
does
vulnerability
scanning
for
vm
images.
C
Maybe
cloud
images
they're
looking
for
vulnerabilities
in
other
formats
than
the
docker
images,
and
if
you
want
to
use
a
tool
like
that,
because
it
offers
container
scanning
as
well
by
all
means
right,
stack
rocks,
can
integrate
with
those
and
use
the
results.
We
think
and
you'll
see
in
a
moment
here.
We
think
it's
more
important
to
understand.
What
are
you
going
to
do
with
that
data?
How
do
I
identify
where
it's
running
and
where
I'm
most
at
risk?
C
So
there's
some
questions
in
here
about
using
ansible.
We
don't
use
ansible,
I
mean
we're
not
an
infrastructure
product
here,
so
the
software
can
be
deployed
as
part
of
really
any
automation.
So
we
have
customers
today
that
are
rolling
out
their
kubernetes
clusters,
with
everything
from
cloud
formation
on
amazon
to
terraform,
ansible
salt
stack,
you
name
it
and
the
stackrock
software
really
just
deployed
on
those
clusters
after
that.
So
we're
not
really.
You
know
we're
not
really
there
to
to
dictate
how
you
guys
build
your
clusters
or
roll
out
your
applications.
C
So
you
can
see
here
a
bunch
of
the
risk
factors
that
have
come
into
this
particular
deployment,
but
you're
also
seeing
some
of
the
runtime
issues.
So
a
lot
of
what
we're
looking
at
is:
how
do
we
harden
an
application
when
it's
being
built
and
deployed?
How
do
we
stop
someone
from
introducing
vulnerabilities?
C
How
do
we
stop
someone
from
over
privileging
a
deployment,
but
also
we
need
to
monitor
these
things
for
when
they're
running
and
here
this
looks
and
feels
a
lot
like
traditional
host-based
intrusion
detection.
We
were
looking
for
activity
inside
of
the
containers
that
indicate
someone's
breached
this
and
doing
something
unusual
now.
The
difference
is
that
there's
a
lot
more
moving
parts
right.
C
If
I
have
a
side
car,
if
I
have
a
series
of
containers
inside
of
a
single
deployment
or
multiple
pods
they're
all
linked
together
here-
and
I
can
see
what
we've
learned
about
this
one
of
the
nice
things
about
containers-
is
that
we
can
use
some
of
the
nature
of
containers
to
to
help
understand
the
context
of
activity
going
on
inside
of
it.
So
you
know,
containers
roughly
put
should
be
boring.
C
They
should
have
a
really
simple
entry
point
and
initialization
process
that
settles
down
over
time,
and
we
can
use
that
idea
that
any
deviation
from
the
norm
or
any
deviation
across
replicas
would
indicate
a
runtime
threat
here.
We
can
also
look
at
some
simpler
signals
like
someone's
trying
to
install
software.
Maybe
I
have
a
good
reason
for
that.
You
know
we
don't
normally
see
things
like
a
bash
shell
being
spawned
by
a
java
application.
C
So
in
this
case
it's
things
like
process
ancestry,
so
we're
examining
the
run
time
for
a
lot
of
these,
both
simple
and
then
more
complex
signals
to
indicate
again
where
you
know
where,
where
things
are
going
unusual,
these
things
are
built
automatically.
They
can
be
enforced
automatically
or
you
can
have
manual
control
over
it.
C
We're
looking
at
the
reporting
here,
we'll
show
you
exactly
what
we
mean
by
enforcement
as
we
get
a
little
bit
towards
the
end
for
that
another
aspect
of
runtime
is
networking.
What
is
this
thing
doing
on
the
network
and
I'll
jump
over
to
the
network
graph
to
show
you
what
we
think
about
here,
and
so
I
know
some
questions
popping
up
about
networking.
C
Our
view
of
networking
is,
of
course,
the
kubernetes
view
about
networking,
so
we're
showing
you
a
live
network
graph
here.
I've
got
multiple
clusters,
so
I
can
switch
back
and
forth.
My
production
cluster
has
a
bunch
of
name
spaces
in
it,
which
are
the
labeled
boxes
here.
So
we
think
it's
you
know
natural
to
organize
things
around
the
way
that
kubernetes
organizes
things
around
name
spaces
within
each
one.
C
I've
got
my
deployments,
so
every
dot
here
actually
indicates
a
given
deployment
and
I
can
look
at
the
flows
and
you'll
see,
there's
no
ip
addresses
and
port
numbers
here,
because
you
know
those
things
potentially
change
right,
they're
flexible,
I
might
have
more
than
one
replica.
We
think
that,
for
you
know
the
proper
understanding
of
this,
we
want
to
understand
the
flows
between
the
deployments
now.
The
other
view
that
I
can
have
here
aside
from
my
active
view,
is
an
allowed
view
and
again
this
is
a
live
environment.
C
So
we're
looking
at
the
actual
configuration
of
this
cluster
and
the
allowed
view
reflects
the
network
policies.
You
can
see
here
that
stack,
rocks
actually
define
network
policies
and
the
word
network
policy
refers
very
specifically
here
to
a
kubernetes
network
policy,
so
this
capability
here
in
stackrocks,
really
gets
to
the
heart
of
what
we
mean
by
kubernetes
native.
You
will
find
in
the
market.
There
are
other
strategies
towards
isolating
applications
from
each
other
within
the
cluster.
C
C
The
goal
here
is
that
for
network
policies
to
be
the
agent
for
that
right,
this
is
kube
native.
This
is
a
part
of
the
the
networking
that
capabilities
that
kubernetes
has
it's
in
line
with
the
way
that
that
kubernetes
defines
these
things
for
every
platform.
That's
out
there
that
runs
kubernetes
today,
so
being
native
to
the
tool,
means
better
for
performance
better
for
documentation
and
understanding
and
you'll
see
that
it's
source
code
right.
This
is
code
that
we
want
to
make
part
of
your
developer's
application
code.
C
This
is
deployment
information
that
should
go
along
with
everything
else.
They're
deploying
it
should
be
part
of
the
application.
This
is
in
line
with
that
idea
that
we
don't
patch
and
maintain
production
environments.
You
don't
apply
rules
separately,
everything
comes
from
source
code
and
your
environments
can
be
built
entirely
by
rolling
out
from
source.
If
you
have
an
automated
your
process,
for
you
know,
let's
say
terraform
or
ansible,
to
build
out
infrastructure.
C
Install
kubernetes
on
top
of
that
run,
applications
that
this
should
be
part
of
that
application
code
from
an
operations
perspective
too.
This
avoids
risk
the
risk
of
a
container
security
product,
whether
it's
open,
source
or
or
commercial
being
in
line,
as
we
would
say
so
in
this
case,
stack
rocks
is
not
in
line.
We
simply
don't
provide
the
firewalling
we're
just
programming
kubernetes
to
do
what
we
think
is
appropriate
here.
So
the
the
the
enforcement
of
this
ultimately
falls
to
components
that
are
part
of
kubernetes.
C
You
can
troubleshoot
that,
with
your
you
know,
standard
tools
and
logging
and
the
teams
there
will
understand
that
hey.
This
is
a
network
policy.
Something
present
it's
in
the
object:
they're
not
going
to
have
to
go
look
into
a
stackrock's
log
to
find
out
why
the
firewall
isn't
processing
there
and
if
a
stackrock's
component
fails,
you
won't
lose
your
network
filtering
or
your
networking
altogether
right.
C
So
I'll
pause
for
a
moment.
There's
any
questions
about
you
know
things
like
you
know,
networking,
etc.
I
see
some
other
things.
Does
it
work
in
conjunction
with
other
tools
like
zscaler?
So
this
is
complementary
to
other
tools.
Right
you'll,
note
very
distinctly
here
that
stack
rocks
is
not
doing
perimeter
security,
we're
not
a
perimeter
security
company.
So
at
the
front
end
of
your
environment
right
out
of
the
at
the
ingress
and
egress
points.
You
know.
We
think
that
that
traditional,
you
know,
perimeter
security
is
important.
C
You
know
things
like
amazon
security
groups
are
used
for
port
and
protocol.
You
know
vpcs
and
acls
like
designing
your
clusters
in
a
secure
way
is
important
too
now
we
do
have
a
guide
to
building
secure,
eks
and
azure
aks
clusters
like
guides
for
how
to
use
the
cloud
environment
to
build
yourself,
a
cluster
that
has
a
good
security
stance
to
begin
with,
but
we
don't
do,
for
example,
like
application
firewalling,
we
don't
do
load,
balancing
and
other
things.
C
We
don't
certainly
don't
do
things
like
ddos,
those
are
the
province
or
the
cloud
providers
or
traditional
vendors
that
you
know
and
tools
on
premise:
we're
just
focusing
on
the
cluster
itself.
Inside
of
the
cluster,
there's
also
a
question
about
istio
and
in
this
demo
environment
I
don't
have
istio
for
those
who
are
not
familiar
with
the
term.
Istio
is
a
service
mesh
and
a
service
mesh
provides
for
moving
into
the
infrastructure,
really
a
lot
of
the
services
that
would
be
part
of
the
networking
here.
Istio
is
really
usually
common.
C
First
use
cases
to
offload
tls
encryption
into
the
infrastructure,
so
that
your
development
teams
don't
have
to
worry
about
certificates
and
all
that.
So
all
of
this
works
with
istio
there's
no
requirement
for
istio.
Here,
though,
so
you
don't
have
to
be
running
a
service
mesh
or
any
other.
You
know
any
other
technology
here.
This
is
part
of
native
kubernetes,
since
you
know
1.9,
I
think
so,
there's
no
requirement,
but
it
works
with
it.
C
So
I'm
going
to
move
on
here
because
we've
talked
a
little
bit
about
you
know.
Actually,
we've
seen
a
lot
about
reporting
information
right
and
that's
a
good
chunk
of
what
we
do,
but
I
want
to
continue
with
this
idea
of
fixing
things
in
the
code,
because
it's
really
critical
that
we
think
about
that
like
if
we
assume
that
a
running
deployment
should
never
be
changed
right.
That's
the
philosophy
behind
cloud
native
is
that
the
infrastructure
specified
in
code.
All
the
application
parameters
are
specified
in
code.
C
So
when
you
have
issues
like
that,
where
we
want
to
do
is
is
point
to
a
way
to
fix
things
in
the
code,
and
you
know
if
I
look
at
my
violations
here,
what
went
wrong?
We
see
this
long
list
of
things
that
are
here.
As
I
pick
these
you'll
see.
You
know,
of
course,
the
details
on
what
what
a
violation
occurred.
What
deployment
so
I've
got
sort
of
a
you
know
a
an
incident
list
here
showing
me
all
of
the
violations
that
have
occurred.
C
But
if
I
dig
down
here
on
the
policy
you're
going
to
see
a
little
bit
of
a
difference
than
I
think
traditional
security
right,
so
we
certainly
want
teams
to
be
able
to
understand.
You
know
what
happened
and
when
for
runtime,
we
want
to
know
you
know
what
was
the.
What
was
the
process
that
ran
here?
What
was
the
user
id
and
then
the
date
and
time?
But
the
goal
here
is
to
go
beyond
that
and
to
help
teams
understand
how
to
prevent
this
from
happening
again.
C
So
every
one
of
the
stack
rocks
policies
that
we
pre-create
that
are
come
with
the
product
are
written
in
this
way,
with
a
description
and
a
rationale
and
remediation
right,
pointing
the
team
towards
the
solution
and
as
much
as
we
can
point
them
towards
a
way.
That's
native
to
to
images
and
to
you
know,
into
kubernetes
you're,
never
going
to
see
from
stack
rocks
a
recommendation.
Hey
go,
install
the
stack
rocks
component
for
this
into
your
container
and
solve
your
problem.
That
way,
it's
going
to
be
like
hey,
your
images
are
too
old.
C
We
want
you
to
rebuild
that
image
from
source
or
we
saw
a
package
manager
being
executed,
and
you
know
like
the
occurrence
of
that,
tells
us
maybe
there's
something
here.
That's
going
on
that
people
shouldn't
be
doing
so.
We
want
to
see
like
basically
a
you
know,
a
trace
here
of
all
the
commands
that
led
to
this,
the
parentage
you
can
see.
This
was
java
spawning
a
bash
shell
spawning
a
package
manager,
but
for
the
developer
right-
and
mostly
the
audience
here-
is
the
development.
C
C
Your
image,
definitions
and
redeploy
in
that
devops
kind
of
way
and
you'll
see
that
as
we
go
through
the
policies
here
and
the
broad
side
of
things
they
cover,
they
all
have
different
life
cycles
from
build
to
deploy
time
to
run
time
and
always
there's
something
that
we
can
do
to
push
the
developers
to
to
to
fix
the
problem
permanently
right
now
here
the
audience
obviously
is
the
devops
team.
I
mean,
if
there's
a
vulnerability
in
an
image.
If
there
is
a
package
present
in
an
image
that
image
build,
is
a
responsibility.
C
The
devops
team
we're
we're
not
asking
the
security
team
to
go
chase
this
down.
We
want
to
short
circuit
that
process.
The
goal
is
to
get
the
security
team
to
set
the
goals
right
to
set
the
guidelines
for
which
these
things
are
acceptable.
Now,
package
managers-
these
are
low
severity.
These
are
probably
not
your
biggest.
You
know
your
biggest
issues.
There
are
other
things
out
here,
for
example
like
using
read-only
root
file
systems
that
teams
devops
teams
especially
find
as
they're
starting
there
for
their
journey
down.
C
You
know
container
and
coop
native
find
difficult
to
to
be
to
implement
right.
These
are
difficult
concepts
to
get
your
head
over
like.
Why
can't
I
write
files?
Why
wouldn't
I
want
to
be
able
to
write
files,
but
the
goal
here
is
to
help
the
whole
organization
move
along
the
the
security
teams
decide
what's
the
most
important
now,
a
lot
of
these
are
written
just
based
on
our
expertise.
C
So
this
is
something
we
want
to
again
push
teams
away,
and
you
know
in
this
case
either
your
own
security,
your
your
own
secret
management
system
or
just
directly
in
kubernetes,
right,
kubernetes
and
openshift
support
secrets.
They
can
be
encrypted.
They
are
you
know,
subject
to
our
back
you'll,
see
that
we
cover
you
know
even
things
like
our
back
and
you'll
see
the
broad
section
of
things
that
we
have
some
of
my
favorite
ones.
You
know
things
like
this.
C
C
There
is
a
way
for
you
to
specify
a
less
privileged
user
account
and
in
kubernetes
or
in
docker,
and-
and
you
should
use
that
so
we're
again
we're
always
pushing
these
teams
towards
how
do
I
best
use
the
platform
for
security
things
like
that.
Come
up
all
the
time.
As
I
mentioned,
role-based
access
control,
some
of
the
defaults
aren't
good.
C
C
Compliance
standards
vary
you'll,
see
here
that
we
support
these
six
standards
today,
two
of
them,
the
cis
benchmarks
here
cover
configuration
of
your
cluster,
in
other
words,
they're,
related
to
how
docker
kubernetes
are
configured
within
the
cloud
environment
or
your
on-premise
environment,
whether
you're
meeting
the
guidelines
recommended
there,
two
of
them
are
nist
standards,
one.
You
know
that
190
document
is
specifically
around
application
containers.
C
So
this
is
a
document
that
explains
how
using
docker
container
images
and
an
orchestrator
the
recommendations
that
are
made,
and
so
things
like
using
a
you
know
a
pipeline
build
approach
right.
In
fact,
if
I
go
back
to
my
policies-
and
I
make
sure
that
I'm
enforcing
my
vulnerability
scanning
in
here,
I
can
claim
to
meet
that
so
as
we,
you
know,
start
to
use
the
tool
to
do
enforcement.
As
I
go
in
and
create
my
rules
here,
I
can
actually
turn
these
things
on.
Save
them
run
my
compliance
scan.
C
C
These
were
written
without
things
like
containers
and
kubernetes
and
mine,
and
so
we
have
to
interpret
what
it
means
by
firewalls
and
again.
Another
reason
why
we've
chosen
kubernetes
network
policies
is
that
choosing
a
standard
here
is
much
more
likely
to
be
accepted
by
an
auditor.
So
if
you
are
subject
to
internal
or
external
audits,
even
if
you're
not
required
to
have
pci
compliance,
you
know
invoking
the
controls
through
the
platform
in
a
repeatable
way,
being
able
to
demonstrate
that
with
a
tool
like
stack
rocks,
we
think
is.
C
C
You
know
ci
cd,
pipeline
tools
or
you
know
things
like
kube
itself
as
far
as
compliance
goes,
but
I
might
be,
you
know,
care
about
my
front
end
name
space
since
kubernetes,
already
embeds
so
much
isolation
into
name,
spaces,
things
like
secrets
and
our
back
are
isolated
by
name
space.
We
think
it's
a
good
boundary
to
create.
You
know
compliance
rule
sets
around
and
segmentation
rule
sets
around.
C
So
if
there
are
any
questions
feel
free.
If
there's
anything
that
you
haven't
seen
that
you
wanted
to,
as
you
can
imagine
here,
as
we
go
through
the
user
interface,
there's
quite
a
bit
more
detail
as
we
drill
down
into
the
various
levels
of
you
know
of
detail
that
this,
the
prep
the
platform
offers,
and
so
we
could
probably
spend
all
day.
But
I'm
happy
to
answer
any
questions.
A
All
right,
let's
see
here,
are
the
results,
looks
like
a
lot
of
compliance
and
vulnerability
management
cool.
Let's
get
to
the
last
question
here,
real
quick-
and
this
is,
if
you
guys,
want
access
to
a
complimentary
30-day
trial.
Just
let
us
know
we'll
reach
out.
Our
trials
are
a
little
different.
We
definitely
walk
you
through
them
and
they're
guided
so
definitely
good
stuff.
There
cool,
let's
see
some
questions
that
I
see
chris
on
my
end
here.
Actually,
since
they're
already
on
the
page,
we're
using
splunk.
C
Yes,
absolutely
so
a
lot
of
what
we
have
here.
I
think
we
make
a
very
pretty
gui,
but,
to
be
honest,
most
of
our
customers
end
up
handling
their
security
issues
and
incidents
in
tools
that
they
already
have
today.
So
we
don't
expect
people
are
going
to
spend.
You
know
have
to
use
all
of
all
of
our
tools
here
or
even
to
prefer
them.
We
know
that
if
you
have
an
instant
response
system
in
an
external
tool
like
splunk
or
google
cloud
security
center
or
sumo
logic,
we
fully
support
that.
C
So
anything
that
you've
seen
in
here,
the
runtime
incidents
that
have
occurred,
even
like
administrative
audit
changes
in
here
all
get
sent
out
to
splunk.
One
thing
I
like
about
the
way
we
handle
notifications.
Well,
there's
two
things
I
like
about
it:
one
is
that
for
the
human
readable
things
like
slack
right,
where
I
want
to
send
a
message
to
somebody
that
actually
goes
to
a
human
being,
the
integrations
actually
support
this
notion
of
labeling
or
annotating.
C
So
we
can
actually
figure
out
from
your
kubernetes
deployment,
assuming
that
you're
labeling
it
correctly
that
we
can
find
out
what
channel
you're
in
and
actually
send
you
things
that
are
relevant
to
you.
So
if
you
can
get
the
teams
to
adopt
this
standard
of
hey,
I'm
going
to
put
my
slack
web
hook
in
my
deployment
or
other
owner
or
contact
information.
It
makes
it
easier
for
the
security
team
to
get
hold
of
people
when
there's
a
problem,
and
it
makes
it
easier
for
tools
like
stack
rocks,
to
be
able
to
send
direct
information.
C
The
same
thing
applies
to
stuff
like
jira.
If
you
could
label
your
your
project
in
here,
we
can
file
bugs
under
the
right
project
heading
in
jira
automatically.
The
other
is
that
a
lot
of
security
tools
are
noisy.
Let's
face
it
right.
They
they
all.
They
do
is
chirp
constantly
about
issues,
and
we
want
to
avoid
that
and
what
we've
built
is
policies
here
that
by
default
don't
send
out
notifications.
C
It's
a
great
way
to
be
able
to.
You
know
to
go
in
and
say:
hey.
You
know
I
got
this
90
day
thing,
but
I
want.
I
don't
know
how
widespread
it
is,
and
I
can
actually
look
here
before
I
apply
it.
Like,
oh
boy.
I
have
a
lot
of
things.
In
other
words,
you
get
a
preview
before
that
noise
comes
in
and
then
also
you
know
you
have
the
option
of
having
a
policy
in
place
that
you
might
want
to
try
to
understand.
C
How
often
does
this
occur
and
you
don't
actually
have
to
put
a
notification
in
there,
so
it
shows
up
in
the
dashboard
it
shows
up
in
violations,
but
it
won't
go
out
to
an
external,
and
so
you
can
experiment
with
policies
like
you
know,
I
want
to
create
a
policy
that
might
measure.
For
example,
you
know
who's
using
privileged
containers
in
the
environment.
C
You
know
overall
or
who
is
or
who
is
not
using
a
read-only
root
file
system
or
show
me
my
you
know,
exposed
services
without
actually
having
to
see
to
have
a
call
to
action
to
it.
There
can
be
those
exploratory
type
of
of
policies,
and
you
know
I
can
have
multiple
notifications
here.
I've
only
got
my
slack
channel
set
up,
but
I
could
have
everything
go
to
splunk
a
subset
going
to
slack.
C
A
C
No,
no
we're
not
so
I
didn't
get
into
that.
But
let
me
let
me
explain
briefly:
it's
it's
not
because
we
couldn't
it's,
because
we
really
don't
want
to
do
that.
So
this
is
something
that
gets
into
the
weeds
of
it.
But
when
you're,
looking
at
security
and
in
a
traditional
vm
environment,
leaving
the
whole
vm
running
but
killing,
let's
say
a
package
manager
or
a
system
tool
is
probably
the
right
way
to
go.
C
Leave
the
rest
of
that
virtual
machine
running
containers
are
not
little
virtual
machines
right,
they're
not
intended
to
have
a
lot
of
different.
You
know
capabilities
all
in
one
running
multiple
services.
They
should
be
laser
focused
on
a
single
service.
Most
importantly,
though,
kubernetes
doesn't
really
deal
with
containers
and
processes
under
the
hood.
It
deals
with
pods
and
it
doesn't
know
the
difference
between
a
pod,
that's
running
correctly
and
one
that's
running,
but
has
some
of
its
process
activity
impaired.
So
when
we
enforce
it
runtime.
You
know
in
this
case,
just
a
really
simple
thing.
C
Somebody
ran
a
package
manager,
but
it
could
also
be
because
hey
we
saw
a
brand
new
set
of
processes
running
or
somebody
tried
to
open
up.
You
know
a
network
port
with
netcat
or
or
other
activity
in
the
container
we
mis-nuked
the
whole
thing
right.
The
application
in
this
case
is
the
whole
deployment
right
and
kubernetes
can
recover
from
that.
It
knows
what
to
do
with
the
deleted
pod.
It
doesn't
know
what
to
do
with
a
pod,
that's
kind
of
sort
of
working.
So
our
approach
here
eliminates
the
attack
it
nukes
the
whole
thing
right.
C
The
whole
pod
is
gone,
whatever
processes
we're
running
and
the
details
of
the
violation
are,
of
course
recorded,
but
the
pod
is
destroyed
and
applications
should
be
able
to
handle
that
I
mean
they
should
be
expecting
that
under
a
kubernetes
environment
that
pods
get
thrown
away.
Occasionally
this
also
allows
us
to
avoid
you
know
a
situation
where
a
fall
is
positive
right
if
a
security
tool
says
hey,
this
looks
malicious
because
a
developer
went
and
logged
into
a
production
container
remotely
and
copied
some
files.
C
Well,
that
looks
like
an
intrusion
and
in
the
case
of
a
false
positive
here,
we've
been
able
to
again
leave
the
application
running
while
knocking
that
developer
out
of
the
environment
that
they're
not
supposed
to
be
logged
into.
So
we
don't
support
that
low-level
process,
interference
because
it
breaks
applications.
It's
not
a
cloud-native
approach
to
to
enforcement.
A
C
Well,
the
big
answer
to
that
question
in
general
is:
is
kube
native
right,
so
we
simply
don't
provide
a
firewall
when
you
think
about
container
and
container
environments
that
are
orchestrated
if
you're
looking
at
supporting
multiple
orchestrators
other
than
kubernetes.
The
only
thing
they
have
in
common
really
is
the
docker
container
runtime
or
the
other
runtimes
that
support
docker
containers.
So
we
did.
We
have
the
luxury,
I
guess
of
assuming
that
you're
running
kubernetes
and
it's
all
we
we
support.
C
So
the
idea
here
is
that
when
the
platform
provides
it,
then
we
don't
need
to,
and
it's
not
desirable
for
a
vendor
like
us
to
be
able
to
provide
a
proprietary
solution
so
most
of
the
products
out
there
will
take
one
of
two
approaches.
Sometimes
both
they
will
either
manipulate
the
underlying
networking
of
the
host
or
the
container
networking
like
directly.
So
in
other
words,
they
have
a
tool
that
puts
an
ip
tables.
You
know
deny
or
or
allow
rule
into
the
kernel
of
the
host,
so
they're
manipulating
the
the
networking
at
a
low
level.
C
Now
that
approach
means
you
have
to
have
their
software
running
the
rules
don't
get
updated
unless
their
software
is
running
and
it
potentially
confuses
kubernetes
and
applications.
Right
teams
will
not
have
a
network
policy
to
look
at
in
kubernetes
to
understand
what's
happening.
Another
approach,
sometimes
called
a
sidecar
or
proxy,
is
one
that
we
think
is
better
suited
for
perimeter,
but
some
companies
are
deploying
this
strategy
internally
to
the
cluster,
where
there
is
from
the
security
vendor
a
networking
pod
of
some
sort.
C
That
is
actually
accepting
terminating
and
you
know,
evaluating
the
network
connections,
in
other
words,
they're
a
live
component,
that's
in
line
with
your
networking,
and
there
are
some
advantages
to
that.
I'm
sure
that
you
get
you
know
more
visibility
and
maybe
more
control,
but
to
us
that's
putting
another
application
component
into
the
application
that
the
team
did
not
build.
They
can't
troubleshoot
and
if
it
fails,
I
mean
networking
fails
right.
We
don't
want
a
security
product
to
be
that
in-line
component
that
jeopardizes
your
application
reliability.
C
So
we've
decided
not
to
take
that
approach
here.
So
the
the
native
approach,
we
think
is,
is
obviously
the
best
one.
I
mean
it's
kubernetes
and
the
the
industry
and
all
the
cloud
providers
and
all
of
the
platform
providers
are
behind
this
approach
and
the
separation
between
the
upper
layer,
network
policy
and
the
lower
level
container
networking
means
that
you
know
there
could
be
innovation
on
on
both
sides.
A
A
We
definitely
want
to
get
a
one-on-one
meeting
with
you
guys
and
there's
a
lot
to
cover,
as
chris
mentioned-
and
this
is
just
a
quick
preview,
we
can
definitely
deep
dive
in
any
kubernetes
security
questions
that
you
guys
have
and
look
out
for
the
on-demand
version
of
the
recording
as
well.
All
right
have
a
nice
day,
guys
bye.