►
From YouTube: DevSecOps Lunch and Learn (Central)
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
Hi
everyone,
and
thanks
for
attending
today's
virtual
Lunch
and
Learn,
my
name
is
Tam
and
I'll
be
moderating.
Today's
virtual
a
day,
I
have
Michael
I
annatee
with
me.
Today
he
is
our
Regional
Sales
Manager
for
the
East,
and
that
includes
the
central
region.
Michael
will
be
giving
an
overview
as
that
rocks
before
he
hands
it
off
to
Chris
Porter
Chris
is
our
director
of
solutions.
Engineering
he'll
be
giving
a
live
demo
of
the
stack
rocks,
kubernetes
security
platform,
all
right
before
I
hand
it
off
to
Michael.
Let's
get
some
polling
questions
started.
A
All
right,
so
are
you
running
Kate's
in
production
today,
yes
or
no
I'll?
Let
this
poll
run
a
couple
more
seconds.
If
you
don't
see
the
poll
pop
up,
you
may
have
pop
ups
disabled
right
now,
all
right.
So
let's
end
the
poll
and
show
the
results.
Look
at
your
answers
in
all
right,
so
about
5050.
Almost
some
of
you
guys
are
in
production
currently
and
some
are
not
alright.
Let's
get
the
second
question
going.
A
B
Yeah
great,
thank
you,
Tim
nice
to
meet
everyone
virtually
I'm
like
a
naughty
one
of
the
Regional
Sales
Managers
here
so
I
want
to
take
you
through
just
a
few
slides
in
PowerPoint.
To
give
you
an
idea,
you
know
what
is
that
crotch
right?
Where
do
we
focus
on
security
and
compliance?
One
of
the
use
cases
we
address
for
our
customers-
and
you
know
what's
different
about
this
approach.
B
We
think
makes
it
compelling,
but
I
will
not
for
you
in
PowerPoint,
very
long
I'll
pass
it
over
to
Chris
shortly
here
to
take
action,
really
good
stuff
and
the
GUI.
So
the
first
thing
is,
you
know:
where
do
we
focus?
And
the
answer
is
nothing
that
you
guys
were
doing
five
years
ago
right
when
everything
was
on
Olympic
applications
running
on
beyonds
or
bare
metal,
and
then
all
the
sudden
docker
came
to
market
about
five
years
ago.
B
Right,
didn't
people
got
excited
about
containerization
and
all
these
promises
are
on
scalability
and
flexibility
that
come
with
containers.
What
we
think
folks
realized
pretty
quickly
was
that
containers
by
themselves
are
very
difficult
to
manage
right
and
don't
come
with
any
inherent
controls,
and
so
we
think
that,
more
recently,
in
the
last
couple
of
years,
there's
been
a
big
shift.
The
focus
away
from
just
containers
towards
containers
with
proper
orchestration,
because
you
know,
with
orchestration
you've
got
the
control
plan
to
manage
containers
and
achieve
better
flexibility,
scalability,
hopefully
some
better
cost.
B
Now
in
terms
of
stack
rocks.
We
think
that
there
was
a
lot
of
solutions
that
came
to
market
in
that
second
phase
right
when
containers
got
popular
to
apply.
You
know
traditional
security
use
cases
to
containers
the
advantage
that
we
think
we
have
as
a
company
as
we
came
to
market
with
this
product
really
the
beginning
of
2019,
and
we
had
a
few
additional
years
to
see
that
90%
of
the
market
was
moving
in
a
kubernetes
direction,
away
from
orchestration
platforms
like
docker,
swarm,
etc.
B
So
we
said:
okay,
we
want
to
build
a
product
which
is
much
more
focused
on
securing
containers
through
the
orchestrator
through
Nettie's,
delivering
security
as
code
through
the
three
Orchestrator
and
we'll
talk
about
just
some
quick
examples
of
that,
and
we
want
you
to
think
about
as
you
look
at
the
demo,
but
from
a
high
level.
You
know
these
are
the
use
cases.
B
These
eight
use
cases
you
see
here
that
we
address
for
our
customers
really
believes
in
like
the
categories
that
we
think
you
know
why
anyone's
gonna
go
out
and
make
an
investment
in
stack
rocks.
It's
going
to
be
a
couple
of
these
reasons,
so
visibility
come
I,
think
you'll
easily
seen
the
demo
kind
of
what
role
this
plays
both
operationally
and
from
a
security
perspective.
Just
do
you
understand,
what's
going
on
inside
of
your
kubernetes
environment?
Vulnerability
management
is
certainly
you
know.
B
One
of
the
first
use
cases
typically
folks
want
to
address
what
we
think
is
most
compelling
about
the
way
that
we
approach
vulnerability
management
is
helping
you
contextualize
risk
within
kubernetes
with
this
deeper
integration.
So
that's
what
we'll
try
to
focus
on
compliance
is
certainly
a
big,
a
big
motivator
for
a
lot
of
customers
right
around
PCI,
HIPAA,
sock,
2
or
just
you
know,
traditional
standards
like
CIS
benchmarks
and
the
NIST
standards,
and
then
you
know
some
things
other
things.
B
What
we'll
talk
about
and
what
I
think
will
be
interesting
here
is
our
approach
through
kubernetes
to
address
things
like
network
segmentation
firewall
within
your
clusters
as
well,
as
you
know,
things
around
configuration
management,
and
certainly
you
know,
threat
detection.
They
think
about
it
traditionally
and
how
it
applies
to
kubernetes
environment
always
asks
about
just
integrations,
so
you
see
down
at
the
bottom
of
the
screen
there.
Some
of
the
product
eyes
integrations.
We
have.
B
This
is
not
a
complete
list,
so
there's
other
things
that
we
can
show
you
in
the
demo
that
we
can
push
or
pull
data
from.
The
important
thing
to
know
is
you
know,
there's
really
no
limits
in
terms
of
what
you
can
integrate
with
us,
whether
it's
productize
or
not.
We
do
have
a
native
web
book
that
makes
it
very
easy
to
tie
into
any
sort
of
tooling
that
exposes
the
API.
B
So
it's
something
we're
working
on
for
customers
all
the
time,
there's
very
little
limits
and
and
you'll
see
some
more
in
the
product
here
and
really
guys.
This
is
just
back
from
this
idea
of
there's
two
Moretti's
native
approach.
Right.
There
are
other
computer
security
products
out
there
we
make.
This
interesting
is
the
way
we're
focusing
on
kubernetes
mints
and
pawns.
B
Really
the
constructs
that
matter
board
of
our
customers
were
focused
on
kubernetes,
and
so
you
know
just
some
of
the
high-level
ideas
that
we
will
have
working
this
closely
with
the
orchestrator
is
around
richer
context.
Right,
not
just
something
you
understand,
you
know
what
motor
abilities
you
have
any
environment,
but
how
do
you
prioritize
them
based
off
of
things
like
well,
you
know:
is
this
in
a
production
environment
or
just
the
test
environment,
and
does
the
container
have
access
to
the
Internet?
B
How
have
you
privileged
the
container
all
of
these
things
and
a
lot
of
other
factors
should
influence?
How
much
you
care
about
any
individual
moaner
ability
or
risk,
and
that's
what
we're
trying
to
help
their
teams
understand
is
where
to
start
where
to
prioritize
in
terms
of
remediating.
Your
biggest
risk
today,
another
one
around
native
enforcement-
and
this
is
really
what
we're
thinking
about
is:
where
can
we
leverage
the
orchestrator
to
do
security
use
cases
for
you?
B
So
Chris
will
show
you,
you
know:
how
will
you
guys
with
a
network
segmentation
and
firewalling,
and
then
we
will
see
throughout
the
platform?
Is
we're
always
looking
for
not
just
not
just
opportunities
to
enforce
security
policies,
but
also
opportunities
to
improve
best
practices
right?
How
how
and
when
can
we
push
back
on
DevOps
team's
developers
to
help
them
learn
more
about
security,
best
practices
so
that
you
know
they
can
deploy
software
as
quickly
and
seamlessly
and
securely
in
the
future?.
C
Right
this
is
Chris
here:
I
want
to
talk
a
little
bit
about
how
the
stack
rocks
product
actually
functions.
So
this
is
a
software
product
and
it's
built
with
a
client-server
architecture
in
mind.
So
you
know
we're
talking
here
entirely
about
kubernetes
security,
and
this
is
a
kubernetes
application.
So
we
wanted
to
feel
and
run
like
other
kubernetes
applications
in
your
environment,
which
means
you
can
deploy
it.
However,
you
like
in
a
variety
of
configurations
with
any
tools
you
could
use
helm.
You
can
use
kubernetes.
C
You
can
use
any
automation
or
deployment
tool
to
roll
out
the
stack
Rox
product.
Another
principle
that
we
have
is
to
keep
the
resource
usage
low.
Everybody
I'm
sure
it's
familiar
with
security
products
that
use
a
large
amount
of
CPU
or
memory
resources
or
require
huge
amounts
of
storage,
we're
leveraging
as
much
of
kubernetes
as
possible
trying
to
keep
this
as
stateless
and
its
minimal
impact,
so
that
you
know,
for
example,
if
you're
running
kubernetes
in
the
cloud
you're
not
forced
to
use
larger
instance
sizes
justice
to
support
a
security
solution.
C
So
you
know
we
use
like
the
rule
of
thumb,
about
1%
of
CPU
usage
here
and
that's
broken
up
into
the
components
that
run
inside
of
each
of
your
clusters,
like
the
collector
and
the
sensor
that
you
see
at
the
bottom
here,
as
well
as
the
central
dashboard
that
runs
in
kubernetes
natively,
built
from
multiple
clusters.
You
know
around
1%
of
your
resources
will
be
used
for
security,
which
we
think
is
a
pretty
fair
price
to
pay
for
the
kind
of
visibility
and
security
that
we're
offering
you
here.
C
All
the
communication
that
you
see
is
all
done
through
through
TLS.
There's,
really
no
restrictions
on
how
you
run
this
the
architecture,
the
cloud
environments
that
you
run
in
you
know
as
long
as
it's
kubernetes.
This
software
is
compatible
and
then
we're
going
to
show
you
some
examples
of
how
this
integrates
with
other
products.
But
there's
one
place
to
configure
integrations
with
things
like
registries
and
and
communications
tools,
CI
CD
pipelines,
etc.
So
we
want
this
to
be.
C
A
C
So
I'm
gonna
change
my
sharing
settings
here
and
bring
up
the
demo
since
we've
got
folks
that
are
looking
for
things
you
know
in
the
near
term
and
other
folks
that
are
looking
for
things
a
little
bit
later
on
we'll
talk
about
some
of
the
broader
topics
as
well
as
some
of
the
you
know
the
near-term,
the
immediate
things
you
can
do
now
we're
we're
running
live
here.
This
is
a
live
demo
of
the
stack
rocks
product
running
in
a
cloud
environment,
as
you
can
see
from
the
dashboard
here.
C
I've
got
two
clusters
that
I'm
actually
looking
at
here
and
I've
got
a
ton
of
violations
and
deployments
stack
rocks
is
a
software
product.
It
runs
in
your
environment
if
you
are
subject
to
things
like
regulatory
compliance
that
makes
things
easier,
you're
shutting
out
us
as
a
vendor
from
ever
accessing
any
of
your
data
and
since
we're
talking
about
security
here,
we're
no
doubt
talking
about
some
sensitive
information.
So
we're
not
a
part
of
that.
We
don't
host
this
dashboard.
C
The
the
software
runs
as
I
said
in
any
kubernetes
environment
and
supports
really
any
kubernetes
clusters
anywhere.
So
the
single
dashboard
can
provide
for
security
and
and
compliance
and
other
visibility
across.
You
know
multiple
environments
and
you'll,
see
too
that
it's
flexible
and
how
we
write
policies
so
that
if
I
do
have
multiple
development
environments,
staging
production,
different
applications,
maybe
you
have
clients
who
demand
their
own
single
tenant
environments
in
the
cloud.
We
can
support
that
model
with
policies
that
are
appropriate
for
each
of
those
environments
from
one
dashboard.
C
Now
this
is
all
driven
by
role
based
access
control
and,
of
course,
I'm
logged
in
here
as
an
administrator,
but
you
can
provide
delegated
access
the
portions
of
the
interface.
We
also
have
other
means
of
approaching
this
through
command-line
interfaces
through
CI
CD
pipeline
integrations
and
then
ultimately,
through
a
fully
documented
rest
API.
C
So
if
you
want
to
pull
data
out
of
this
system
or
have
it
push
data
to
another
system,
we
can
certainly
do
that,
and
I
would
be
remiss
if
I
didn't
mention
that
we
also
have
a
cool
dark
mode
in
the
UI,
so
that,
if
your
preference
working
from
home
these
days
and
have
a
darkened
room,
however,
you
want
to
use.
It
is
fine.
C
There's
flexibility,
its
ability
to
solve
business
problems
quickly
to
understand
the
nature
of
infrastructure
is
code
where
we
specify
everything
is
part
of
a
deployment
and
fixins
don't
happen.
In
other
words,
you
don't
patch
and
maintain.
Instead,
the
strategy
here
within
within
DevOps
is
it's
a
rebuild
to
fix
the
issues
at
their
source
and
redeploy
right,
and
that's
that
the
philosophy
that
we
think
kubernetes
was
built
for,
of
course,
kubernetes.
Wasn't
really
built
with
security
in
mind,
but
a
lot
of
what
you're
going
to
see
here
is
that
stack
rocks.
C
C
Now
we
think
it
goes
beyond
that,
but
we
do
think
that
it's
an
important
part.
We
think
that
overall,
it's
really
important
to
know
where
your
images
are
coming
from
like
where
the
developers
are
getting
them
from.
Are
they
coming
from
well-known
curated
sources?
Are
they
coming
from
open
source?
Are
they
built
entirely
in-house
and
we
think
it's
obviously
it's
important
to
know
what's
in
them
and
there's
a
couple
of
things
that
we
can
see
right
away
from
this
report?
C
One
is
that
there's
a
lot
of
vulnerabilities
here,
there's
going
to
be
one
of
the
challenges
of
vulnerability
management
is
that
if
I
have
three
hundred
and
sixteen
vulnerabilities
they're
running
in
four
different
deployments,
I
have
many
different.
You
know
objects
that
I'm
dealing
with
that's
one
of
the
challenges
of
kubernetes
security
compared
to
traditional,
even
even
cloud
security.
Is
that
we're
potentially
dealing
with
a
lot
more
moving
parts.
Of
course,
inside
of
every
image,
I
have
components,
those
components
again
come
from
various
sources.
This
is
a
lot
of
cats
to
herd
right.
C
We
could
point
to
a
couple
of
things
to
make
this
easier
right,
reduce
the
noise.
A
little
bit.
One
stack
rocks
is
gonna
focus
on
the
fixable
field.
Right
fixable
means
that,
for
you
know
a
given
vulnerability.
If
I
look
at
the
details
of
this,
it
looks
like
the
expat
library
again,
this
is
live
so
I'm.
Just
looking
at
this
right
now,
I
can
see
that
this
is
fixable,
meaning
that
the
owner
of
the
package
or
the
company
that
produced
it
has
published
a
fixed
version
of
it.
C
I
can
also
see
that
it's
very
serious
on
a
scale
of
you
know,
10
being
the
worst
here.
The
the
CSS
9.8
means
that
there's
a
very
strong
likelihood
of
this
being
exploited
and
the
exploit
results
in
an
attacker
having
a
high
level
of
control.
So
the
the
focus
here
on
fixable
and
serious
means
that
you
know
we're
justified
in
telling
a
team
that
you
can't
use
this
image.
C
You
have
to
go
out,
update
your
images
or
use
a
different
image
that
doesn't
have
this
present,
because
it's
easily
fixed
another
aspect
of
container
security,
and
this
is
something
that
you
and
your
teams
can
go.
Look
at
right
now
without
without
having
stack
rocks
in
house.
One
of
the
things
that
we
see
often
is
is
exactly
here.
This
is
the
build
for
this
given
image
and
the
build
happened
a
long
time
ago
and
in
security,
especially
in
kubernetes,
security
and
container
security
age
is
the
enemy.
Freshness
of
images.
C
So
before
I
move
on
from
vulnerabilities,
are
there
any
questions
coming
up
in
the
Q&A
I
know
we
can
we
can
stop
any
time
so
some
questions
about
you
know:
how
do
we
find
this
information?
How
do
we
scan
these
these
images?
So
that's
a
great
question,
so
stack
rocks
includes
components
of
the
software
that
scan
all
images
that
we
see.
The
images
are
broken
down
into
layers
and
then
from
layers
into
components
and
those
are
mapped
to
you
know
vulnerability
scanning,
so
the
vulnerability
data
is
updated.
Often
it
comes
from
public
sources.
C
It
comes
from
language
packages,
operating
system
producers,
so
in
general
the
list
is
kept
up
to
date
and
the
images
are
parsed
as
they're
they're
used
now.
Some
other
questions
in
here
about
other
things
that
we
can
look
at
in
the
image
and
we
certainly
parse
the
fullness
of
images
right.
We're
looking
at
labels
we're
looking
at
all
the
layers.
C
You
know
it's
a
ton
of
detail
here
that
we
could
certainly
go
into,
but
I
want
to
broaden
the
approach
a
little
bit
here
and
move
on
to
what
we
call
risk,
because
images
are
just
one
component
of
it,
and
this
is
where
we
start
to
differ
from
other
solutions
out
there
in
the
marketplace
and
focus
on
kubernetes
security.
I
think
starts
to
become
pretty
evident
when
I
moved
to
my
risk
report.
I'm
no
longer
looking
at
images
I'm
now
looking
at
deployments,
and
that
could
be
true
deployments.
C
It
could
be
replica
sets,
it
could
be
other
types
of
applications
in
kubernetes
and
they're
organized
by
clusters
and
namespaces.
So
this
is
our
kubernetes
focus
where
the
reports
are
organized
around
the
objects,
the
the
divisions
that
that
the
kubernetes
has
natively.
The
priority
here
is
stack,
rocks
way
of
ranking
the
security
risk
in
your
environment
and
if
I
click
on
one
of
these
you'll
see
that
that
risk
ranking
includes
vulnerability
data,
but
it's
not
limited
to
that.
C
We
think
that
vulnerability
data
is
only
one
way
to
look
at
the
security
risk
here,
for
example,
in
this
summary,
we're
seeing
that
I
have
a
container
running
as
privileged
mode
I
have
not
specified
any
CPU
or
memory
limits
in
my
deployment,
which
means
that
this
is
a
blast
radius
problem.
So
it's
a
configuration
that
the
developer
could
have
provided,
which
would
restrict
how
much
CPU
or
memory
a
an
attacker
would
be
able
to
use
or
a
runaway
container
would
be
able
to
use
so
we're
missing
that
protection
here.
C
I
can
also
see
that
I've
got
a
port
exposed
and
it
happens
to
be.
You
know,
port
22
for
for
secure
shell
and
that's
a
little
unusual
right.
We
don't
want
to
see
folks
exposing
ports
for
remote
access
in
a
kubernetes
application,
especially
not
in
production
you'll,
see
down
here
that
we
classify
that
under
we
call
service
reach
ability
really
simply,
if
you
have
a
vulnerability
in
a
running
container,
the
container
is
exposed
on
the
network
means
it's
more
likely
to
be
to
be
breached
right.
C
It's
a
really
simple
example
of
correlating
information
from
the
image
right,
the
vulnerability
information
about
the
image,
along
with
the
information
that
hey
this
is
actually
something
I
can
get
to
on
the
network.
We
also
classify
other
things
inside
of
an
image
right.
One
of
the
the
principles
of
container
security
is
that
you
should
use
minimal
images
with
this
little
software
installed
on
them.
As
you
need
right,
if
possible,
swap
out
using,
you
know,
Lube
unto
or
alpine
linux,
for
a
dedicated
scratch
or
minimal
operating
system
that
runs.
C
You
know
in
this
case
just
enough
to
get
Java
started,
so
the
other
components
that
come
with
those
operating
system-
images
like
package
managers,
user
shells,
Network
utilities-
are
useful
if
an
attacker
compromises
that
container
so
getting
rid
of
that
stuff
just
makes
their
job
harder.
Lastly,
down
here
we're
also
looking
at
how
does
kubernetes
interact
with
this
at
all?
C
If
at
all,
and
in
this
case
I've
got,
you
know
a
really
bad
situation
way
down
here
in
the
lower
right
that
this
particular
deployment
is
running
with
a
service
account
that
has
cluster
admin
privileges,
and
this
might
seem
a
little
bit
of
a
you
know
contrived
for
this
demo,
and
we
certainly
do
put
it
together
to
look
good
in
here.
But
this
happens.
If
you're,
using
tools
like
helm
to
helm,
has
the
tiller
component
and
tiller
runs
as
a
cluster
admin.
C
Typically,
in
most
environments,
see
ICD
tools
like
Jenkins
might
run
as
cluster
admin,
and
that
admin
privilege
is.
You
know,
when
is
what
it
sounds
like.
If
you
compromise
that
and
take
the
are
back
rules,
you
can
access
any
part
of
the
kubernetes
cluster
that
you've
compromised,
so
I
can
launch
other
containers.
I
can
access
storage
devices
it's
kind
of
game
over
if
I
compromise
in
your
environment,
if
an
attacker
compromises
a
cluster
admin
level
of
privilege.
C
Now,
if
you're
looking
closely
here,
you
might
have
also
seen
some
runtime
activity
and
that's
the
kind
of
the
next
stage.
We've
looked
at
the
vulnerability
data,
we
call
the
build
information
where
this
comes
from.
What's
in
it,
we've
looked
at
some
of
the
configuration
like
networking
and
privilege
levels,
but
process
execution
inside
of
each
container
is
something
that
we
provide
visibility
for
and,
of
course,
we're
tracking
this
and
looking
for
security
incidents,
in
other
words,
the
the
signals
that
match
patterns
of
a
breach
going
on
in
my
environment.
C
So
things
like
you
know,
this
is
a
job
application.
I
can
drill
down
into
the
the
process
information
here.
So
if
a
java
application
is
running-
and
it
spawns
a
bash
shell
right
user,
interactive
shell
to
run,
commands
that
pattern
of
behavior
matches
attacks
and
involve
things
like
ransomware,
crypto
miners
being
downloaded,
so
we're
looking
specifically
for
that
signal.
We
also
take
advantage
of
the
fact
that
containers
are
not
meant
to
be
maintained,
right,
they're,
lightweight,
they're,
throwaway
and
so
the.
If
there's
an
indication
that
someone
is
attempting
to
maintain
to
change
or
install
software.
C
C
And,
of
course,
you
know
things
like
netcat
nmap
curl,
w
get
a
whole
host
of
applications
are
really
useful,
troubleshooting
tools,
but
they
don't
belong
in
production
environments
and
when
they
run,
we
can
use
that
as
an
indicator
of
an
incident
going
on,
of
course,
to
the
last
capability
that
we
can
look
at
here.
Another
broad
strategy
towards
that
we
can
use
for
containers
is
container
should
be
boring
when
they
run
right.
They
really
ought
not
to
be
doing
a
whole
lot
other
than
starting
in
an
entry
point.
C
You
know
running
some
initialization,
maybe
they
you
know
set
some
variables
and
the
like
and
then
generally
start
either
a
language
interpreter
or
a
binary.
That
is
gonna.
Listen
for
services
right.
If
they
follow
that
pattern,
we
can
use
that
to
essentially
build
a
baseline
of
model.
So
we
observe
this
for
a
period
of
time
and
across
replica
sets
to
understand
what's
normal
for
this
particular
deployment
and
then
track
deviations
from
it
in
this
environment
because
of
the
sort
of
declarative,
lockdown
nature
of
containers,
the
immutable
nature
of
them
we're
not
supposed
to
change
it.
C
There's
a
bunch
of
signals
that
we
can
use-
and
you
know
basically
boring-
is
good.
We
want
to
see
our
containers
running
in
a
boring
way,
we're
going
to
get
more
into
the
runtime
here
and
we're
going
to
talk
more
about
policies,
the
the
the
overviews
that
you
see
here
there,
any
questions
about
risk
or
back
on
vulnerability
management
that
I
can
address.
C
That's
a
great
question
so
well:
I
can
jump
over
and
talk
a
little
bit
about
that.
The
aspects
that
we've
seen
here
like
vulnerability
data
like
network
port
exposure.
These
are
things
that
that
we
can
actually
get
before.
Somebody
runs
things
so,
while
this
is
running
right
now,
my
visa
processor
and
my
my
back
end
outlets.
These
are
all
running
right
now
in
a
kubernetes
cluster
we'd
rather
get
to
this
information
prior
to
it.
Getting
here
in
the
environment,
now
you'll
see
it
in
the
tab
here
that
I've
got
a
Jenkins
environment
running.
C
C
So
when
you
saw
the
highlights
here
in
my
in
my
summary
of
policy
violations
that
actually
generated
a
much
more
detailed
response
as
part
of
the
policy
body,
and
this
is
a
huge
focus
of
what
we
do-
it's
about
empowering
developers
to
solve
the
problems
on
their
own
so
that
the
security
team
set
the
goals
like
I.
Don't
want
to
see
a
package
manager
left
in
your
images
or
I.
Don't
want
you
exposing!
You
know
port
22.
C
These
are
things
that
we
can
surface
right
at
the
point
where
they're
being
built
before
they
get
deployed
before
it
becomes
a
problem
that
I
have
to
deal
with
in
an
incident
response
fashion.
If
I
want
to
nudge
people
towards
specifying
resource
limits
and-
and
hopefully
you'll
see
a
few
things
about
this
one-
it
is
front
and
center
the
developers
don't
have
to
be
knowledgeable
about
kubernetes
security.
They
just
want
to
understand.
Like
okay,
there's
something
here
that
I
can
do
about
this
problem,
there's
very
precise
feedback
about
how
to
resolve
this.
C
In
the
case
of
things
like
you
know
like
like
knowing
resource
requests
being
specified
or
a
package
manager
being
put
in
here,
we're
not
trying
to
inject
any
additional
software
or
any
other
controls
in
this
environment
right
Zak
rocks.
It's
not
here
to
you,
know,
voice
more
software
on
your
did,
there's
no
libraries
to
build
into
their
containers
or
any
other
sidecar
objects
running
in
their
environment.
We're
really
just
telling
them
that
hey
there's
a
feature
of
docker
or
kubernetes
that
you
should
be
using
or
that
you're
using
in
the
wrong
way.
C
We
don't
want
you
to
use
privileged
containers.
We
want
you
to
go
and
understand
that
hey
kubernetes
natively
supports
this
idea
of
CPU
and
memory
limits,
and
we
want
you
to
specify
them.
What
I
really
like
about
this
solution
as
a
former
developer
many
years
ago,
I
love
that
it's
not
a
black
hole
and
I
love
that
I
can
get
some
of
these
things
as
like
a
hint
in,
but
because
here
you
can
see
that
my
build
actually
succeeded.
C
So,
in
other
words,
step
one
for
implementing
stack
rocks
is
start
to
notify
teams
that
were
watching
and
we're
gonna
help
you
with
these
issues.
If
I
go
back
to
my
project,
you'll
see
that
in
the
next
build
what
I
did
here
was
actually
change.
The
setting
in
the
stack
rocks
interface.
So
imagine
the
security
team
now
decides.
You
know.
We've
had
enough
problems
with
privileged
containers,
we've
educated
the
team-
and
you
know
now
I,
want
to
say,
hey
we're,
not
gonna,
let
you
run
a
privileged
container
without
some
special
exception
right
privilege.
C
Containers
have
access
to
the
hosts
that
they're
running
on,
which
means
again
game
over.
If
this
is
compromised,
a
privileged
container
has
the
rights
and
the
rest
of
the
environment
can
access
the
hosts
and
storage
and
other
containers.
It's
a
it's
a
really
bad
situation
to
be
found
in,
and
so
it
should
be
used
very,
very
sparingly.
So
in
this
case
my
build
failed
and
we're
also
going
to
talk
a
little
bit
about
like
what
happens
when
somebody
ignores
this,
because
if
I
say
I,
don't
care
that
this
failed
I'm
gonna
deploy
it
anyway.
C
We've
got
to
be
able
to
put
a
protection
into
the
clusters
themselves
and
we'll
talk
a
little
bit
about
that.
So
getting
back
to
my
demo
here,
I'm
actually
gonna
talk
about
one
more
thing
related
to
reporting
and
risk,
and
then
we
can
zoom
right
into
like
remediation
like
what
do
we
actually
do
about
these
problems
before
I?
Do
that
I
want
to
point
out?
C
Another
cool
thing
about
the
product
here
is
that
it's
all
searchable
so
I
like
to
point
out
that
the
pages
in
the
UI
here
are
really
good
places,
if
you're
not
sure
what
you're
looking
for
you
want
to
go
in
and
find
out
like.
What's
the
top
priority,
we
can
help
guide
you
there,
but
often
customers
do
have
an
idea
of
what's
wrong
and
what
they're
looking
for,
for
example,
I
mean
to
know
for
impacted
by
some
new
or
some
old
vulnerability
and
that
search
that
ability
to
go.
C
Look
at
here's,
my
running
deployments
or
if
I
look
in
my
global
search,
I
can
actually
search
across
deployments
and
images.
I
can
find
a
complete
record
of
where
everything
is
running
in
my
environment.
I
can
even
query
on
other
attributes.
I
love
this
I
love
the
ability
to
go
in
and
say
you
know
it's
bad
practice
to
run
an
interactive
shell
like
bash
as
part
of
my
deployment
who's.
C
Doing
that
like
this
is
a
process
search
that
allows
me
to
look
in
every
container
across
every
deployment
across
every
cluster
to
see
what
exactly
is
going
on.
You
know
if
I
want
to
find
out,
do
folks
even
have
a
particular
component
installed,
because
I
need
to
know
if
you
know,
there's
usage
of
a
given
library
out
there,
like
this
asset
inventory
again,
can
answer
questions
for
you,
but
I
quickly
want
to
get
into.
C
Is
another
exciting
part
about
run
time
security,
which
is
if
job
number
one
here
is
I,
want
to
stop
attackers
from
getting
into
my
environment
and
reduce
the
chances
that
they
can
get
in
then
well
right
behind
that
job
number
two
is
defense
in
depth
and
be
able
to
to
contain
them
when
they
that
compromise
happens.
Obviously
things
like
privilege
levels
are
an
important
part
of
that,
but
the
next
part
of
it,
of
course,
is
is,
is
isolating
them
on
the
network,
so
for
good
security.
C
You
know
defense
in
depth
for
typically
for
compliance
reasons
and
for
just
the
general
sanity
of
knowing
that
environments
are
isolated
from
each
other.
We
want
to
promote
the
idea
of
segmenting
your
container
clusters,
you're,
probably
all
familiar
with
firewalling
and
network
segmentation,
and
most
environments
have
something
in
place
today,
if
you're
using
a
cloud
environment,
you're,
probably
using
security
groups
and
ACLs
in
your
network,
what
we
find
less
common
is
segmentation
within
the
kubernetes
clusters
themselves.
C
They're
often
designed-
and
you
know,
for
productivity
reasons,
they're
set
up
as
big
flat
networks
where
everything
can
communicate
with
everything
and
that's
good
until
you
run
into
a
problem
right.
Flexibility
is
a
great
goal,
but
it's
not
the
best
for
security.
Well,
organizations
aren't
aware
that
kubernetes
even
even
has
this
by
default,
so
we're
trying
to
bring
light
to
that
we're
trying
to
show
you
what
your
clusters
look
like.
C
What
units
are
communicating
with
each
other,
so
I
can
show
you,
for
example,
that
my
my
Postgres
deployment
has
been
talking
to
an
API
server
here.
Give
you
different
time
frames
to
view
that
and
shed
light
on
what
is
the
traffic
among
my
services
in
my
cluster.
The
goal
here,
of
course,
visibility.
But
the
other
goal
is
to
use
this
information
to
help
teams
limit
what
this
traffic
is.
C
If
I
don't
see,
for
example,
my
front
end
and
my
back-end
directly
communicating
well,
then
maybe
there's
a
candidate
there,
where
I
can
isolate
these
two
environments
from
each
other.
So
you
can
see
that
in
the
last
24
hours,
these
two
don't
have
a
line
connecting
them
and
so
they're,
not
you
know,
they're
not
set
up.
You
know
to
need
that
communication.
If
I
switch
to
the
firewall
view
here,
you'll
see
again
that
you
know
the
the
environments
are
open
to
each
other.
The
red
here
allows,
for
you
know
this.
C
This
wide
open
communication,
so
you
can
see
from
the
legend
here
that
I've
got
all
connections
allowed
if
I
click
on
that
and
I
look
at
the
details.
This
is
why
there
are
no
network
policies
applied
here
and
by
network
policies.
I
mean
an
object
in
kubernetes
called
a
network
policy,
so
this
is
one
of
the
places
where,
as
a
software
security
company,
we've
made
a
choice
and
we've
chosen
to
support
kubernetes.
So
when
we
talk
about
isolating
traffic,
we
talk
about
doing
it
with
the
controls
available
to
you
in
every
kubernetes
cluster
right.
C
That
means
that
kubernetes
has
a
standard
for
defining
these
rules
and
we
want
you
to
use
them.
We
think
the
best
way
is
to
program
kubernetes
to
segment
your
traffic
for
you,
you
know
in
lieu
of
proprietary
solutions
out
there.
So
when
we
provide
tools
like
this,
this
is
our
policy
simulator.
This
is
gonna,
make
recommendations
on
network
policies.
It's
going
to
allow
that
traffic
that
we've
observed,
but
close
it
down
so
that
other
traffic.
C
You
know
the
unused
paths
my
front
end
and
my
back
end
environments,
not
talking
to
each
other
is-
is
actually
embraced
in
the
code
here
and
hopefully
you
could
see
a
few
things
about
this
one.
It
is
bog
standard,
kubernetes
right.
Many
people
are
surprised
to
find
out
that
kubernetes
supports
effectively
layer-3
firewalling,
it's
native,
it's
built-in
and
we're
here
to
promote
that
use
of
that.
The
other
is
that
this
is
code
right.
This
is
declarative.
C
It's
designed
to
go
along
with
the
the
rest
of
the
code
that
defines
your
application,
so
that
code
can
include.
You
know:
docker
files
for
building
those
images.
Of
course,
your
source
code
and
all
of
the
artifacts
that
are
being
put
into
those
images.
It
can
mean
your
kubernetes
amol,
that's
used
to
deploy
it,
and
it
also
means
this
because
you
know
in
a
DevOps
environment
where
your
even
your
clusters
might
be
ephemeral.
Right,
I
can
stand
up
and
teardown
clusters.
You
know
many
times
per
day.
C
The
other
thing
that
I
can
offer
you
about
this
approach.
Is
that
there's
not
a
stack
rocks
component
that
will
interfere
with
your
networking?
So
you
know
if
the
stack
rocks
software
which
you
can
see
in
here
has
any
kind
of
failure
or
blip,
because
we
are
not
doing
the
parsing
of
the
network.
We're
not
looking
at
the
packets,
we're
not
enforcing
the
rules.
C
Natively,
there's
no
component
here
in
stack
rocks
that
could
fail
and
cause
an
outage
right
and
we're
not
going
to
cause
the
networking
between
two
components
to
suddenly
blip
because
it
simply
doesn't
pass
through
our
software.
You
know
we
can
drill
in
here
to
what
what
the
stack
rocks
is
doing,
but
we
of
course
supply
network
policies
because
we
believe
in
this
model
and
we
want
to
protect
our
application
from
anything
else.
That's
running
in
there.
A
C
The
difference
really
is
to
focus
on
kubernetes.
So
when
we
build
rules
when
we
measure
when
we
audit
your
I'm
here,
to
show
you
what
the
status
of
this
is
we're
measuring
only
those
rules
that
are
based
on
you
know
on
the
stack
on
the
kubernetes
network
policies.
This
means
they
could
have
come
in
from
elsewhere
if
your
teams
are
accustomed
to
building
them.
But
it's
not
something.
That's
going
to
be
proprietary
to
our
solution.
It's
also
in
line
with
how
we
want
kubernetes
to
be
in
charge
of
your
applications
to
understand
the
state.
C
Kubernetes
is
designed
to
have
a
stated.
You
know
goal
in
a
state
of
operations,
and
that
applies
to
things
like
availability
and
recovery,
but
we
think
it
also
should
apply
to
security
for
the
most
part,
competitive
solutions
out
there
that
work
on
the
container
right
and
they
work
in
every
environment,
including
non
kubernetes
environments-
are
either
instrumenting
the
docker
engine
or
the
container
engine
or
the
container
itself,
or
they
have
some
form
of
proxying
or
other
interface
with
the
network
layer
and
and
for
all
the
reasons
that
I
mentioned
right.
Non-Standard
potential
for
risk.
C
We
find
that
companies
that
are
using
those
solutions
are
actually
not
able
to
use
that
component.
There's
too
much
risk
involved
in
you
know
depend
depending
on
it,
or
you
know
the
the
the
performance
and
other
aspects
of
running
it
are
not
acceptable.
So
we're
you
know
here
to
say
that
a
proprietary
solution
is
likely
to
read
lead
to
risk
that
the
world
is
kind
of
settled
around
kubernetes
network
policies
and
we're
big
fans
of
using
it.
I.
C
Also
want
to
get
back
to
that
concept
that
we
talked
about
here,
where
you
know
what
I'm
defining
is
is
code
right.
This
is
the
nature
of
kubernetes
that
we
want
to
declare
things
to
be
in
a
particular
state,
and
the
kubernetes
system
strives
to
reach
that
state
and
when
we
find
an
issue,
even
if
it's
something
like
a
runtime
issue
like
hey,
we
saw
somebody
making
a
you
know.
You
know
a
curl
connection,
running
netcat
installing
software
using
a
package
manager.
C
So
even
if
it's
a
runtime
thing,
that's
not,
you
would
think
really
a
part
of
the
configuration.
There
is
a
code
change
that
we
can
make,
but
we
talk
about
runtime,
being
an
opportunity
for
learning
from
production
and
then
hardening
the
environment.
So
this
is
what
a
policy
looks
like
in
stack
rocks.
C
We
saw
a
hint
of
that
in
the
Jenkins
output
here,
but
the
idea
here
is
that
every
policy
in
stock
rocks
has
a
rationale
and
a
remediation
we're
explaining
to
the
security
teams
we're
explaining
to
the
developers
why
this
is
important
and
what
they
can
do
about
it.
Now,
this
one
is
a
low
level.
You
know
severity
here,
I'm,
not
suggesting
that
you
go
out
and
you
know
immediately
halt
all
application
development
until
things
are.
You
know
this
is
fixed,
but
I
love
the
idea
that
we
can
nudge
people
towards
the
right
solution.
C
You
know
if
I
look
at
my
policy
language
here
the
policies
are
written
and
we
define
a
whole
bunch
of
them
for
you,
you
can
use
them,
you
can
modify
them.
You
can
throw
them
all
out
and
start
over,
but
everything
is
written
with
this
developer
audience
in
mind
because
when
you're
running
a
live
production
environment,
but
the
goal
is
not
to
change
that
running
environment,
but
rather
to
fix
it
in
the
code.
C
It's
really
the
DevOps
teams
that
that
are
going
to
be
responsible
for
that
and
to
understand
what
we're
implying
about
things
like
hey,
rebuild
your
images.
Often
don't
use
elevated
privileges.
You
know
we're
not
going
to
let
you
deploy
if
you
have
a
particular
version
of
a
particular
package
out
there.
What
we
really
want
to
do
is
make
sure
that
it's
in
the
hands
of
the
right
teams
and
the
role
for
security
here
is
to
decide.
Where
does
this
apply?
Which
of
these
policies
are
important?
C
What
is
acceptable
risk
versus
you
know
not
acceptable,
even
things
that
are
more
or
less
like
workflow
errors,
like?
Are
you
trying
to
pass
secret
information
like
a
password
through
an
unencrypted
path
like
environment
variables?
Are
you
trying
to
mount
privilege
volumes
on
the
host
and
then
begin
into
things
that
I
would
call
like
advanced
security?
You
know,
I
think
someone
asked
on
the
chat
a
little
bit
about
this,
like
how
do
we
know
if
someone
is
doing
something
like
this
running
things
as
route
or
one
of
my
favorites,
which
is?
C
Are
you
using
a
read-only
or
read/write
route
file
systems?
This
is
something
where
you
know
in
in
containers.
We
can
actually
enforce
the
idea
that
a
container
is
ephemeral
that
you're
not
supposed
to
write
temp
files,
pid'
files,
you
know
anything
else
to
disk
and
expect
it
to
be
there
right.
The
container
may
go
away
at
a
moment's
notice
and
the
application
should
be
resilient
to
that.
So
we
can
actually
put
a
hard
line
of
enforcement
on
that.
But
again,
this
is
not
a
stack
rocks
feature.
C
It
is
us
telling
your
teams
that
in
kubernetes
you
can
specify
in
your
security
context
that
this
is
going
to
have
a
read-only
root
filesystem.
We
love
this
because
it
eliminates
a
whole
class
of
attacks
at
runtime.
You
know,
runtime
can
include
attacks
an
attempt
to
drop
a
payload
on
disk
for
execution
modifying
the
container
to
maintain
a
backdoor,
or
you
know
you
know
installing
something
that
can
sniff
on
the
network.
C
To
exfiltrate
data
we
want
to
do
is
eliminate
the
possibility
of
that
and
a
couple
of
different
settings,
like
you
know,
using
a
read-only
root.
Filesystem
eliminates
a
lot
of
that
now.
The
reason
I
I
said.
Let's
call
this
advanced
is
because
for
teams,
especially
those
that
are
new
or
teams
that
are
migrating
existing
applications
from
traditional
infrastructure
to
containers.
C
Obviously,
here
the
policies
are,
you
know,
there's
tons
of
them
built-in.
They
all
share
these
attributes,
where
you
know
one
of
the
one
of
the
most
common
questions
that
we
get.
So,
if
you're
about
to
answer
this
one
I'll
preempt,
you
you
know,
can
I
decide
to
whitelist
some
deployment
or
image
or
something
and
yes,
there's
a
whole
series
of
scoping
rules
that
you
can
write,
because
we
know
that
certain
things
like,
in
fact
my
Jenkins
deployment
here
is
running
in
the
cluster
and
it
is
going
to
run
certain
things
that
look
bad
right.
C
It's
gonna
build
software,
it's
gonna,
manipulate
the
kubernetes
environment,
so
I
understand
that
I
might
want
to
go
in
and,
let's
say
and
and
whitelist
to
give
a
namespace
like
Jenkins
in
my
environment,
because
you
know
I
have
an
understanding
of
what
that
tool
is
doing
and
I'm
accepting
of
that
risk.
Here
now
when
it
comes
to
a
policy
again,
it's
not
just
enough.
We
focus
a
lot
here.
Is
that
Roxxon,
educating
and
informing,
but
there
are
T's
here
and
we
can
fail
your
environment
when
a
security
condition
warrants
that.
C
So
we
saw
earlier
that
my
build
failed
here
in
jank,
because
I
didn't
meet
the
requirements,
so
I
have
to
resubmit
and
rebuild,
but
I
mentioned
that
people
could
get
past
that.
How
do
I
get
past
that
well
I
ignore
the
C
ICD
process.
I
connect
the
kubernetes
directly,
maybe
even
on
cluster
admin,
I
go
in
and
I
just
say.
You
know,
I
want
to
deploy
this,
and
so
what
we're
gonna
do
is
instrument
the
kubernetes
cluster
itself
to
enforce
this
right.
C
What's
called
the
admission
controller,
it's
part
of
kubernetes
right,
it's
being
used
to
validate
input
provided
to
the
kubernetes
api
server,
we're
gonna
plug
into
that
to
make
use
of
the
the
idea
that
we're
gonna
get
this
information
before
it
gets
created,
we're
gonna
be
able
to
parse
the
Yambol.
That's
contributed
as
part
of
the
the
request
and
essentially
decide
whether
or
not
it's
gonna
be
allowed.
Does
this
meet
the
security
requirement?
If
not,
we
reject
it
right
up
front
again
that
clear
message
is
sent
back
to
the
deployment
tool.
C
So
if
this,
if
I'm
playing
with
this
in
a
console,
if
I'm
using
a
deployment
tool,
the
output
of
the
admission
controller
says
very
clearly,
this
did
not
get
created.
This
is
the
reason
why
and
teams
are
forced
to
to
go
and
manipulate.
You
know,
change
their
settings
and
get
in
compliance
before
they
can
deploy
that
I
know
running
short
on
time
and
I'm.
One
last
thing
that
I'd
like
to
show
you
guys,
obviously
there's
a
lot
more.
C
That
we
can
look
at
here
and
see
is
a
couple
of
times
we
haven't
even
gotten
into,
but
I
like
to
finish
up
with
compliance,
because
it
is
the
overarching
goal
for
a
lot
of
the
organizations.
And
you
know
a
lot
of
companies
in
the
security
space
out
here.
For
years
will
have
you
know,
documents
telling
you
how
to
be
PCI
compliant?
They
have.
You
know,
PDF
that
you
can
follow
along,
and
you
know
check
the
boxes
on.
C
We've
integrated
those
kind
of
checks
here,
natively
in
the
product,
so
that
you
can
see
immediately
where
you
are
and
are
not
in
compliance
and
what
that
means
like
down
to
the
individual
controls,
we're
providing
guidance
on
what
are
the
settings
and
the
capabilities
that
you
need
to
be
taking
advantage
of
here
in
order
to
provide
this
control
and
to
demonstrate
that
you're
in
compliance
with
it.
So
that
means
again
adopting
standards
right.
C
Another
reason
for
network
policies
is
that
if
you
have
PCI
components
or
HIPAA
or
anything
else
that
requires
isolation
of
data,
an
auditor
is
more
likely
to
accept
something
that
is
going
to
be
a
standard
that
they
can
go
and
look
at
out
there.
So
when
we
talk
about
PCI
compliance
for
cardholder
data,
we
mean
network
policies.
When
we
look
at
things
like
you
know,
vulnerability
management.
Looking
for
you
know
unnecessary
software,
again
we're
looking
at
translating
those
in
terms
of
what
are
the
network
services
that
are
open,
but
not
accepting
traffic.
C
You
know
those
capabilities
here,
all
translated
in
terms
of
the
tools
that
are
available,
so
we
go
further
I
think
than
anyone
else,
but
it's
really
about
connecting
the
dots
here.
If
you
ask
your
team
to
be
PCI
compliant,
you
know
what
does
that
exactly
mean?
What
lines
of
my
kubernetes
yeah
Mel
do?
I
need
to
change
in
order
to
be
in
compliance
with
that
and
I
think
we're
doing
a
better
job
than
anyone
else.
C
So
providing
you
with
that
guidance
again,
like
every
other
report
and
every
other
system
in
this
interface
you'll
see
that
everything
is
also
arranged
around
namespaces
and
and
clusters.
We
think
that's
really
important.
So
one
of
the
non
stack
Rox
recommendations
we
make
around
security
is
kubernetes
has
namespaces
you
should
use
them.
Namespaces
already
provide
a
level
of
isolation
between
applications
with
things
like
roles
and
and
privileges
with
secrets.
C
It's
not
truly
multi-tenant
in
many
environments,
but
with
the
addition
of
things
like
network
policies
between
namespaces
and
other
restrictions,
you
can
get
there,
and
so
the
namespace
is
a
good
way
to
start
thinking
about
isolating
components
or
applications
from
each
other
or
even
different
teams
in
the
same
kubernetes
clusters
and
then
as
I
like
to
say,
with
compliance
you're
only
as
compliant
as
you
can
demonstrate.
So
the
reports
here
are
exportable.
C
The
nice-looking
graphs
can
be
exported,
but
also
as
a
spreadsheet,
because
your
auditors
are
gonna
want
evidence.
Files
they're
gonna
want
a
very
thorough
listing
of
all
of
the
controls,
all
of
the
objects
and
the
you
know
the
failing
pass
status
of
all
of
that
so
being
able
to
hand
them
a
complete
summary
of
the
environment
for
whatever
standards
you
guys
are
looking
at
meeting.
It's
certainly
something
that
we
can
do
right
here
in
the
product.
C
So
I've
been
talking
quite
a
bit.
I
get
very
excited
about
all
these
topics.
So
I'll
try
to
answer
some
more
questions
here.
If
you
have
any
more
about
anything
anything
that
you
hope
to
see
that
I
haven't
covered,
we
can
certainly
try
to
address
that
here.
So
there's
some
questions
back
going
back
to
things
like
you
know,
Bowl
management.
C
How
do
we
collect
you
know
the
data
so
sack
rocks
is
designed
as
a
software
that
pulls
down
the
vulnerability
data
from
you
know:
internet
sources
right
the
common
source
is
the
Linux
distributions,
the
language
provider.
So
there's
a
variety
of
sources
that
we
collect
in
one
place
now.
Sacré
does
not
require
internet
access.
It
can
be
deployed
in
in
completely
offline
environments
that
don't
have
direct
access
to
the
Internet.
We
do
have
a
process
for
updating
and
information
of
the
other
other
environments.
So
some
of
the
components
of
stack
rocks
that
you've
seen
here.
C
I
can
actually
show
you
this
in
the
integrations.
We
do
provide
an
integrated
image
scanner
if
you're
already
using
an
image
scanner
out
there,
if
you're,
using
a
tool
that
say
scans.
You
know
cloud
machine
images
or
you
know
virtual
machines
in
a
VMware
environment,
and
it
happens
to
support
vulnerability
scanning
for
images.
Stack
box
can
actually
use
that
as
a
source
of
data.
If
you
prefer
for
us
it's
more
about
what
you
do
with
the
data
and
rather
than
where
it
comes
from
hey.
A
C
Yeah,
so
obviously
stack
rocks
is
deployed
in
environments
where
security
information
is
gathered
from
not
just
kubernetes,
but
a
lot
of
other
environments
and
Splunk
or
sumo
logic
here
as
a
sim
tool
is
an
ideal
way
to
do
that.
And
of
course,
we
support
that
here.
In
fact,
Splunk
is
one
of
our
biggest
customers
they're,
actually
using
this
as
part
of
their
their
kubernetes
efforts,
their
digital
enablement,
so
setting
up
Splunk
is
really
easy.
It's
quick
to
set
up
the
results
there
are,
you
know
easily
parsed
in
JSON.
C
One
thing
I
like
about
all
these
integrations
is
that
you
can
be
very
selective
about
what
you
send
there.
We
want
to
avoid
that
flood
of
alerts
that
constantly
comes
out
of
a
lot
of
security
tools,
how
to
be
selective
and
make
it
useful
and
actionable
so
you'll
see
here
things
that
are
you
know
human
readable,
like
slack
channels
where
I
might
send
this
information
and
what
I
love
about
this
approach
is
that
if
you've
got
multiple
slack
channels,
multiple
teams,
we
can
actually
use
metadata
from
kubernetes.
C
If
your
teams
would
label
their
deployments
with
their
slack
web
hook
or
their
email
address
or
their
JIRA
project,
we
can
actually
send
things
to
the
right
place
like
get
this
embedded
within.
You
know,
within
the
environments
that
the
tools
that
you
guys
are
using
there
some
questions
about
network
policies.
Do
you
need
to
have
them
in
your
in
your
environment?
I'm,
not
sure,
I
understand
the
question
there,
but
network
policies
they
ultimately
do
depend
on
a
container
networking
interface
under
the
hood
to
do
the
enforcement.
C
So
tools
like
calico
out
in
the
cloud
or
on
platforms
like
OpenShift
or
you
know
in
vmware
the
underlying
networking
provider,
the
Sdn
in
the
environment.
It's
actually
what
does
the
enforcement,
and
so
you
know
the
kubernetes
network
policies
are
a
high-level
definition
of
those
rules.
The
enforcement
is
left
to
the
infrastructure.
As
far
as
I
know,
like
every
major
you
know,
cloud
provider
out
there
and
every
major
Sdn
provider
supports
those
network
policies.
C
A
Okay
cool,
so
what
are
your
top
three
use
cases
for
security
for
your
kubernetes
environment,
and
this
you
can
select
your
top
three
now
let
this
run
a
little
bit.
Your
choices
are:
a
visibility
of
vulnerability
management,
compliance
network
segmentation,
configuration
management
or
at
detection
and
incident
response,
so
I'll.
Let
that
go
a
couple
more
seconds
before
I
close
it
and
share
the
results.
A
All
right,
let's
check
it
out
so
like
Chris
mentioned
compliance,
it's
definitely
something
that
you
guys
are
looking
into
and
then
we
can.
There
are
a
lot
more
questions
coming
through.
So
I
just
wanted
to
mention
real
quick.
If
you
wanted
to
share
the
other
slide
Chris,
we
started
a
meetup
group
if
you
guys
want
to
check
it
out.
This
is
the
East
Coast
one
like
I
mentioned
earlier,
Michael
importer
or
on
the
East
Coast
team,
but
that
also
includes
the
central
territory.
A
So
if
you
guys
want
to
check
it
out,
we'll
be
doing
a
lot
of
cool
little
talks,
virtual
meetups
for
the
time
being
until
we
can
actually
see
each
other
face
to
face
so
check
out
the
meetup
group
and
then
I
just
wanted
to
touch
base
on
next
steps.
Before
we
answer
a
couple
more
questions,
so
look
out
for
I,
guess
next
slide:
Chris
yeah.
B
A
Look
out
for
a
follow-up
from
our
team
we'd
like
to
get
your
DevOps
and
security
teams
together
just
to
go
over
a
deep
dive
session.
What
Chris
showed
you
is
a
great
preview
but
like
he
said
there
are
definitely.
You
know
more
in-depth
things
that
we
could
definitely
show
you
best
practices
for
community
security
and
we'd
love
to
help
guide
your
team's
on
that.
So
look
out
for
that.
We'll
definitely
secure
a
one-on-one
meeting
with
your
team's
and
then
again,
like
I
mentioned
before
there
is
a
swag
offer.
A
So
if
you'd
like
a
t-shirt,
kubernetes
t-shirt
or
some
sack
rock
socks
or
a
pack
of
laptop
stickers
just
fill
out
the
questionnaire
and
the
follow-up
email
and
then
we'll
get
that
sent
directly
to
you,
guys
cool.
So
let's
say
we
still
have
about
a
minute
left.
So
I
just
want
to
ask.
Maybe
one
or
two
more
questions
this
one's
a
good
one?
How
do
you
guys
work
with
sto?
Is
that
something
we
can
cover?
Yeah.
C
Absolutely
so,
for
those
of
you
not
familiar
with
sto
or
service
meshes
right.
This
is
a
layer
on
top
of
kubernetes
that
allows
for
a
lot
of
advanced
capabilities
in
in
networking,
so
things
like
TLS
all
float
are
usually
the
focus
and
for
the
most
part,
snack
box
is
not
really
impacted.
By
this
we
run
fine
in
sto
environments.
In
fact,
we
run
in-house
with
with
a
lot
of
his
ta
components.
C
We
do
track
things
like
sto
vulnerabilities
and
others
to
make
you
aware
that
the
components
that
actually
run
the
service,
mation
kubernetes,
are
potentially
subject
to
attack
and
you'll
see
some
blog
entries
on
our
site
about
how
customers
are
using
sto
today.
So
it
works.
Fine
and
the
product
is
capable
of
handling
sto
or
other
surface
mesh
environments,
along
with
kubernetes.
A
Cool,
thank
you
so
much.
It
looks
like
we
hit
our
time,
so
there
are
some
questions
that
we
didn't
get
to
answer.
We
will
reach
out
to
you
guys
and
answer
that
via
email,
thanks
again
for
joining
and
you'll
have
the
on-demand
recording
later
this
week.
So
look
out
for
that
as
well.
Have
a
nice
thank.