►
From YouTube: Mitigating Kubernetes Attacks
Description
Join our Office Hours to get your questions answered on mitigating K8s attacks.
During Office Hours, our Co-founder and Chief Strategy Officer, Wei Lien Dang, and our Director of Solutions Engineering, Chris Porter, will cover:
- key tactics and techniques you can expect attackers will use on Kubernetes clusters
- the range of Kubernetes-specific and cloud-specific controls to apply
- a prioritized list of mitigation steps you should apply to give you the broadest protection
A
Hello:
everyone
thanks
for
joining
the
september
office
hours,
I'm
chris
porter,
I'm
the
director
of
solutions,
engineering
at
stackrocks
and
I'll
be
moderating
today's
office
hours.
I
have
with
me
today
waylon
deng
joining
me,
he's
our
co-founder
and
the
chief
strategist
at
stack
rocks
if
you
haven't
joined
one
of
our
office
hours
webinars
before
welcome.
Thank
you
for
joining
us.
These
work
a
little
bit
differently
than
other
webinars.
These
are
not
going
to
be
just
a
presentation.
A
There's
going
to
be
q
a
and
we'll
talk
a
little
bit
about
that
this
month.
Our
topic
is
going
to
be
on
mitigating
kubernetes
attacks.
The
mitigating
cooperatives
attacks
is
a
series
of
articles
and
webinars.
If
you
look
in
the
interface
you'll
see
in
the
lower
left
a
set
of
resources
that
you
can
link
to
some
of
that
subject
matter
before
we
get
started
and
before
I
let
way
introduce
himself
we're
going
to
go
over
just
how
this
has
worked
a
little
bit.
A
The
lines
are
muted,
the
session's
being
recorded,
though
so
you'll
have
an
option
to
get
the
an
on-demand
recording,
we'll
send
out
a
link
to
every
one
post
event,
because
this
is
office
hours.
We're
really
just
going
to
be
answering.
Questions
live
from
from
you
in
the
audience,
because
the
lines
are
muted
you'll
have
to
put
your
questions
in
the
q:
a
module
on
the
right
hand,
side
of
the
screen,
so
you
know
any
relevant
kubernetes
topics.
A
Security
cloud
hit
us
up,
get
those
questions
in
there
and
if
we
don't
get
to
all
those
questions
in
today's
session,
we
will
make
sure
to
reach
out
via
email.
We
will
make
sure
that
your
questions
get
answered.
We
have
a
time
seeing
people
with
some
some
trouble
with
the
webinar
console.
Usually
a
browser
refresh
will
fix
that.
So
give
that
a
try.
A
If
you
can't
hear
if
you're
missing
some
of
the
video
and
and
then
let's
we'll
get
started
here
before
we
do
anything
else,
I
want
to
start
with
a
poll
question.
So
we
asked
this
on
all
of
our
webinars
if
you've
joined
us
before
you'll
see
that
some
of
these
questions
look
familiar,
but
the
first
question
we're
going
to
ask
is
really:
are
you
running
kubernetes
in
production,
meaning
you
have
a
kubernetes
environment
where
you're
running
applications
that
are
considered
to
be
production?
A
And
we'll
give
everybody
a
few
seconds
to
answer
that.
So
are
you
running
kubernetes
in
production
today,
I've
been
really
surprised
to
see
how
the
progress
of
this
over
the
last
few
months,
the
answers
here
has
been-
have
been
progressing.
We'll
have
a
couple
more
poll
questions
for
you.
This
one
should
be
pretty
simple,
so
give
everybody
just
five
more
seconds
to
answer
this.
A
All
right
and
here's
our
results,
so
64
of
you
said
yes,
that's
great.
I
mean
we.
We
started
this
a
few
months
ago.
Generally,
the
answer
was
less
than
50
50,
so
most
teams
not
running
that
in
in
production.
Today,
anyway,
let's
get
started
with
some
questions
way.
Thanks
for
joining
me,
I
want
you
to
introduce
yourself
here
and
then
we'll
get
started.
I'll
start
peppering,
you
with
questions
here.
B
Oh
thanks
chris
and
you
know,
hey
everyone
and
thanks
folks
for
joining
us.
You
know
this
afternoon.
My
name
is
william
dang,
co-founder
and
chief
strategy
officer
at
stack
rocks.
I
work
on
a
number
of
different
initiatives
and
you
know,
including
our
most
recent
one,
which
is
writing
about
kumay's
attacks,
specifically
the
kubernetes
attack
matrix.
B
A
So
let's
get
started
with
some
questions
and
this
one
actually
going
to
be
one
that
we
get
quite
a
bit,
so
I
think
we'll
jump
on
this
one
right
away.
So
we
talk
a
lot
about
kubernetes
and
your
series
of
articles
really
addresses
the
ins
and
outs
of
the
kubernetes
infrastructure
applications
running
on
them
and
all
of
that
security.
Now
you
know
from
experience.
I
know
that
most
of
our
customers
and
prospective
customers
run
kubernetes
on
one
of
the
cloud
platforms.
A
You
know,
maybe
it's
azure
kubernetes
service,
it
could
be
amazon,
eks
or
google,
or
even
a
platform
provider
like
red
hat
or
rancher.
Or
something-
and
you
know
security
is
a
part
of
those
offerings.
So
the
question
really
is:
do
I
do
I
have
what
I
need?
Don't
the
cloud
providers
do
the
security
that
I
need
to
mitigate
attacks
against
kubernetes
applications.
B
You
know
these
are
things
like
you
know,
eks
and
gke
and
aks,
and
you
know
there
are
huge
benefits
to
you
know
going
with
a
cloud
provider
for
kubernetes.
You
know,
among
them
security
benefits.
You
know,
but
I
think
the
way
the
right
way
to
sort
of
approach.
You
know
how
cloudfire
can
benefit
you
from
security
standpoint
with
kubernetes
is
you're
part
of
the
broader
shared
responsibility
model.
You
know
cloud
providers
are
going
to
help.
B
You
know
operationalize
and
manage
and
administer
various
components
throughout
the
kubernetes
cluster
they're,
going
to
help
with
the
control
plane.
Components
are
going
to
help
lock
down
node
components
in
the
sense
that
you
know
many
of
them
offer
your
hardened
container
specific
operating
systems,
and
so
all
of
those
things
have
you
know,
benefits
from
the
standpoint
of
security.
You
know
they're
gonna
help
patch
and
upgrade
versions.
B
You
know
that's
one
of
the
starting
points
for
maintaining
solid
kubernetes
security.
We've
seen
you
know
various
types
of
kubernetes
vulnerabilities
being
exposed.
You
know
that
can
be
addressed
through
you
know,
upgrading
versions
or
various
patches
and
so
you'll
definitely
get
those
benefits
from
the
cloud
provider
and
yet,
at
the
same
time,
there's
still
a
lot
of
controls
and
settings
that
you
know
that
are
primarily
set
default
that
you
may
be
insecure,
which
may
need
to
be
configured.
You
know
to
meet
your
requirements,
you
know
a
good
example
of
this.
Is
you
know?
B
B
It's
left
up
to
you
to
specify
you
know,
authorized
permissions
with
things
like
role
based
access
control.
You
need
to
ensure
that
your
applications
are
utilizing.
Ideally,
you
know
mutual
tls,
you
know
for
traffic,
and
so
you
know
I,
I
don't
think
it's
sufficient
to
leave
it
to
the
cloud
provider
for
all
aspects
of
security.
However,
I
do
think
that
cloud
provider
offerings
can
really
help
with
security
and
provide
a
very
good
starting
point.
B
A
Yeah,
I
know
I
think,
what
you
what
you
described
there
fits
in
perfectly
with
that
that
shirt
responsibility
model.
You
know
amazon
talks
about
these
terminology
and
that's
where
I
have
some
of
my
certifications.
They
talk
about
security
of
the
cloud
and
security
in
the
cloud
and
I
feel
like
there's
an
analogy
there
to
security
of
the
cluster
and
security
in
the
cluster
right
that
with
kubernetes.
You
have
responsibility
for
both
of
those
aspects.
You
are
running
new
new
infrastructure
and
the
cloud
providers
provide
tools.
A
You
know
some
of
the
simple
recommendations
we
make
like
not
exposing
your
clusters.
You
know
api
endpoints
on
the
internet,
but
they're
not
going
to
be
enforced,
they're,
not
going
to
be
something
that
you're
going
to
get
by
default
and
with
a
lot
of
the
cloud
providers
leaning
towards.
I
think
they
lean
a
little
bit
too
much
towards
convenience
right
if
things
are
done
in
a
convenient
way.
That
makes
it
easy
to
get
started
rather
than
you
know
the
more
the
more
secure
option
so
yeah
so
jumping
in
folks.
A
A
A
So
if
you
have
any
questions,
we'd
love
love
to
hear
them.
I
do
have
some
other
things
that
we've,
you
know,
we've
heard
pretty
commonly
in
the
past,
and
and
this
is
kind
of
relevant
you
know-
you've
been
working
on
this.
This
kubernetes
attack
framework
right.
So
how
does
that
relate
to
the
miter
attack
framework?
And
where
does
this
come
from
like?
What's
what's
the
goal
behind
this
project,
do
you
think.
B
B
You
know
for
thinking
about
different
types
of
attacks
and
how
they
can
be
categorized,
and
so,
if
you
think
about
that
context,
you
know
the
attack
matrix,
really
extension
of
some
of
the
principles
that
underlie
the
miter
framework.
You
know,
which
is
you,
have
different
types
of
attacker
techniques
which
are
really
more
about
the.
How
an
attacker
might
go
about
taking
specific
actions.
B
They
reflect
specific
methodologies
that
are,
you
know
at
an
attacker's
disposal
in
a
given
environment,
in
this
case
kubernetes
and
then
they're
categorized
on
the
basis
of
you
know
what
an
attacker
is
trying
to
accomplish,
and
so
you
know
those
are
categories
called
tactics,
and
so
you
know
the
cube
attack
matrix
is
made
up
of
nine
tactics
and
40
individual
techniques.
You
know
within
those
nine
tactics
and-
and
there
is
overlap-
you
know
there
are
different
techniques
that
can
be
utilized
to
achieve
different
objectives,
but
you
know,
I
think,
what
the
framework
provides.
B
Is
you
know
this
almost
like
knowledge
base
or
or
way
to
to
better
understand?
You
know
what
are
the
things
an
attacker
might
try
to
do
and
then
how
specifically
might
they
try
to
accomplish
them?
And
there
are
other
attack
matrices
that
exist.
You
know,
there's
attack
matrix
for
enterprise,
there
are
different
types
of
platforms,
but
you
know
sort
of
taking
this
consistent
approach
to
how
we
we
think
about
different
types
of
threat.
Vectors-
and
you
know-
that's
very
powerful
because
it
allows
you
to
think
more
holistically.
B
You
know,
particularly
with
respect
to
the
tactics
you
know
holistically
and
more
comprehensively
about.
You
know
how
you
might
deal
with
different
types
of
threats,
and
the
reason
for
that
is
you
know
we,
you
often
see
you
know
different
types
of
incidents
or
security
issues
that
are
publicly
disclosed,
or
you
see
them
in
the
media,
and
you
know,
while
those
are
worthwhile
to
help
you
understand,
you
know
what
could
go
wrong
or
or
you
know
how
we
could
you
know
what
we
might
better
need
to
protect
against.
B
We
don't
want
to
treat
those
as
sort
of
a
one-off
or
deal
with
them
in
an
ad-hoc
manner.
You
want
to
make
sure
that
you're
dealing
with
them
systematically
that
you're
thinking
about
how
these
might
relate
to
other
similar
types
of
attacks
and
address
those
all
at
once
and
and
that's
what
sort
of
the
attack
matrix
and
attack
framework
allow
us
to
do.
A
That's
really
great
one
of
the
some
of
the
follow-on
questions
from
that
would
be
that
in
in
your
guide,
in
some
of
the
articles
you
talked
about
using,
you
know,
kubernetes
native
controls,
like
ways
that
are
sort
of
you
know
become
available
in
this
build
deploy
runtime
how
to
model
to
mitigate
some
of
these
attacks,
things
that
wouldn't
be
available
in
traditional
infrastructure.
Can
you
give
an
example,
maybe
something
that
would
be
like
a
kubernetes
native
control
that
I
can
use
to
defend
my
applications.
B
Certainly
there
are
several
you
know
I'll
highlight
just
a
few
today,
but
you
know,
I
think,
one
of
the
great
things
that
the
kubernetes
community
you
know
has
has
done
and
undertaken
is
to
think
about
how
you
know
as
a
modern
infrastructure
platform.
Security
can
be
better
incorporated
and
how
we
can
better
address
security
problems
through
controls
and
capabilities
that
are
available
and
built
into
kubernetes
itself,
and
so
you
know
that,
of
course
you
know
there
are
a
wide
range
of
different.
You
know
security
problems,
you
might
look
at
you
know.
B
Looking
at
a
kubernetes
environment,
you
might
focus
on
the
cluster
level,
you
might
focus
on
individual
pod
level
and
so
a
couple
of
the
capabilities.
You
know-
and
you
know
that
can
really
have
high
value
impact
on
your
security
posture
that
are
available
in
kubernetes
to
be
configured.
These
are
things
like
you
know,
role-based
access
control,
which
you
know
allow
you
to
you
know,
set
permissions
and
privileges
on
what
users
and
you
know,
applications
can
do.
There's
network
policies
which
allow
you
to
segment
your
network,
including
part-to-pod
traffic.
B
There
are,
you
know,
pod
security
policies
which
allow
you
to
you
know,
configure
settings
and
harden
you
know
pods
and
containers
at
a
more
granular
level.
You
know
there's
secrets
built
into
kubernetes,
you
know
which
is
really
about.
You
know
allowing
you
to
utilize
sensitive
data
and
and
credentials
for
your
for
your
applications,
and
so
all
of
these
are
you
know
very
rich
capabilities
that
you
know
can
be
taken
advantage
of
and
leverage
you
know
to.
A
Great
yeah,
I've
been
I've,
been
surprised.
The
number
of
assessment
environments
we
get
into
where
not
only
they're,
not
aware
that
kubernetes
has
an
rbac
subsystem
but
sure
enough.
Every
developer
in
the
organization
is
using
a
cluster
admin
level
of
access
to
manipulate
objects
and
run
applications,
and
you
know
that's
a
quick
path
to
a
privileged
escalation
and
it
risks
not
just
your
app
but
but
every
application
running
on
the
same
cluster
so
keep
an
eye
out
for
for
our
back.
So
we
don't
have
any
many
too
many
questions.
A
In
the
meantime,
I'm
going
to
pause
for
a
second
and
ask
another
poll,
question
of
the
audience
here
and
ask
about
container
security,
and
if
this
is
an
active
project,
you
know
by
the
nature
of
the
topic
today,
I'm
assuming
that
you
have
an
interest
in
security
if
you've
joined
us
here,
and
so
we
want
to
ask
you
know
what
the
timeline
is.
We're
trying
to
gauge
whether
or
not
teams
have
thought
about
security
up
front.
A
A
All
right,
last,
three
months,
that's
great
over
time.
These
polls
have
trended
towards
more
kubernetes
production,
use,
more
of
an
awareness
and
a
concern
about
security,
all
good
stuff.
Thank
you
everyone,
so
we
do
have
some.
We
do
have
some
question
here
actually
from
from
nick
about
secrets
actually-
and
you
know
one
of
the
pros
and
cons
of
using
the
kubernetes
native
secrets
injections
versus
something
commercial,
like
a
hashicorp
vault
to
distribute
those
secrets.
B
Yeah
I
mean,
I
think
one
of
the
biggest
advantages
you
know,
of
course,
is
that
you
know
it's
built
into
kubernetes
operationally
it's
going
to
be.
You
know
a
lot
simpler
and
easier.
I
think,
there's
there's
those
operational
considerations.
I
would
say
over
time
you
know:
kubernetes
itself
has
taken
steps
to
better
protect,
you
know,
secrets
and
made
advancements
there.
For
instance,
you
can
encrypt
secrets
now
in
in
ncd
and
so
on.
B
I
think
you
know
where
you
know
and
chris
might
have
an
opinion
here,
but
I
think
where
we
see
customers
looking
at
you
know,
maybe
external
secret
stores
like
hashicorp
vault
and
so
on
is
really
when
you
want
to
think
about.
You
know
secrets
not
just
for
you
know,
containers
and
kubernetes
you
might
you
know
you
might
be
thinking
about
how
you
want
to
manage
that
type
of
data
and
credentials
for
other
environments
too,
and
so
it
provides
a
more
unified
secrets,
management
solution.
B
A
A
If
your
secrets
have
to
be
backed
by
hsm,
you
need
to
get
in
and
have
a
service
that
can
have
that
kind
of
of
hardware,
backing
the
the
secret
store.
So
yeah,
there's
good
reason
to
use
those
third-party
products.
We
would
certainly
recommend
something
it
works
with
kubernetes
right.
We
want
to
make
sure
that
you
know
that
you're
that
you're
still
thinking
about
the
platform
as
being
you
know,
kind
of
in
charge
of
everything
here:
okay,.
B
Go
ahead,
just
one
thing
to
mention,
is
you
know
I
I
do
think
you
know.
Operational
complexity
should
not
be
overlooked,
that
there
is
more
complexity
to
sometimes
sometimes
running
third-party
solutions,
and
so
those
those
considerations
should
just
be
weighed
alongside
you
know
what
what
you're
trying
to
accomplish.
You
know,
I,
I
don't
think,
there's
any
there's,
no
right
or
wrong
answer
here.
I
think
that
it's
kind
of
what
comes
down
to
best
suits
your
needs,
but
I
think
there
are
benefits
and
and
trade-offs
on
both
sides.
A
B
Yeah
that
that's
that's
a
great
question,
you
know,
I
I
think
first,
you
know
it.
It
partly
depends,
I
think,
on
what
environment
you're
running
in
you
know.
We
see
a
lot
of
organizations
who
are
running
cloud,
for
instance
using
cloud
provider
registries.
This
is
like
you
know:
amazon
elastic
container
registry
or
google
container
registry
and
so
on.
If
some
of
the
ones
you
mentioned
like
harbor,
those
those
would
be
standalone,
you
know
so
so
it's
partly
depends
on.
You
know
what
what
environment
you're
running
in.
B
I
think
each
of
them
has
different
security
implications.
You
know
some
registries
have
image
scanning
as
an
example
built
in,
and
so
you
can,
you
know,
scan
for
vulnerabilities
that
exist
in
images
stored
in
those
registries
easily.
You
know,
google
container
registry
has
you
know,
google
container
analysis,
which
is
a
good.
You
know
just
one
example
of
that.
You
know.
Amazon
ecr
also
has
scanning
available,
and
so
you
know
there
are
aspects
that
will
help
with
security.
I
think
you
know
what
you
know.
B
One
one
thing
that
is
probably
key
is
you
want
to
set
up.
You
know
ensure
that
you
have
a
private
repositories,
you
know
and
then
separately,
but
we
still
do
see
a
lot
of
your
organizations
and
users
pulling
from
public
registries
like
docker
hub,
and
you
know
when
you're
doing
that
you
do
need
to
ensure
that
you
know
specific.
You
know
security
policies
are
set
in
place.
You
know
perhaps
access
policies
as
well,
because
you,
you
may
pull
something
inadvertently
or
otherwise,
and
you
know
there
are
examples
of.
B
For
instance,
you
know
backdoor
images
existing
on
docker
hub
or
those
types
of
things
leading
to
other
security
issues,
but
also
I
just
want
to
point
out,
since
you
asked
about
notary
notary
is
not
actually
a
registry.
That
is
a
project
that
will
enable
image
timing,
which
is
also
a
separate.
You
know
maybe
requirement
for
some
folks
or
use
case
that
you're
looking
to
address.
B
If
you
want
you
know,
additional
or,
or
you
know,
sort
of
enhanced
image
assurance
around
your
images
that
you're
you're
deploying
after
they're
built
and
so
that
that
might
be
another
consideration
alongside
the
registry.
But
you
know,
I
think
there
are
a
lot
of
registry
options
out
there.
I
think
the
key
factors
to
keep
in
mind
are
you
set.
You
know
ensuring
that
your
images
are
private
and
managed
and
can
be
you
know,
accessed
securely
and
then
separate
from
that.
B
Some
of
the
operational
considerations
of
you
know
whether
you
want
to
run
your
own
registry
or
utilize.
One,
that's
managed
for
you
like
what
a
cloud
provider
would
do
and
then
third,
you
know
whether
you
care
about
image
scanning
being
built
into
that
registry
or
not
or
if
you're
gonna
run
a
stand-alone
image
scanning
solution
right.
A
A
Back
to
that
topic,
we
often
talk
about
here
at
stacks
about
controlling
your
software
supply
chain.
You
know
where
the
library
is
coming
from,
where
the
image
is
coming
from,
like
these
are
artifacts
these
components
that
you're
getting
it
they're
coming
from
an
outside
source.
You
have
that
that
risk
of
them
potentially
being
compromised-
or
you
know
at
least
incomplete
right
and
so
potentially
potentially
jeopardizing
your
application
there.
I
would
say
that
it
is
one
of
the
top
recommendations
that
we
make
is
restricting
the
registries
that
your
kubernetes
clusters
can
use.
A
Some
teams
chase
at
that
a
little
bit
because
they
love
pulling
from
docker
hub
and
having
that
flexibility,
as
we
said
you
know,
putting
some
additional
controls
around
that
sort
of
unknown
stuff
is,
is
probably
the
best
recommendation
that
that
we
can
make
so
we've
got
a
few
more
questions
coming
in
here.
I'm
not
sure
that
we
can
that
we
can
address
all
of
them
here.
Alex
asked
about
opa
and
we're
familiar
with
this,
and,
and
it's
been
a
pretty
good,
you
know,
there's
been
quite
a
few
questions
about
it.
A
B
Yeah,
so
you
know
you
know,
opa
you
know
is,
is
you
know,
I
think,
a
very
exciting
project?
It's
actually,
you
know,
I
would
say
gain.
You
know
substantial
attention
and
traction
within
the
community.
It's
recently
just
recently
actually
applied
for
for
cncf
graduation,
which
I
think
you
know
reflects
that
that
interest
and
and
attention
you
know,
I
think,
the
way
to
think
that
you
know
what
opa
really
is
is
it
provides?
You
know
a
broader.
B
You
know
more
extensible
way
of
thinking
about
policy
management
and
poly
and
policy
enforcement
for
modern
applications.
You
know
beyond
just
kubernetes,
specifically,
though
I
think
there
are
a
lot
of
tie-ins
in
ways
that
the
community
is
thinking
about
incorporating
opa,
you
know
into
kubernetes,
you
know
to
enable
certain
types
of
functionality.
B
You
know
the
the
most.
You
know,
I
think,
probably
one
of
the
areas
that
has
gotten
the
most
attention
for
where
opa
can
help.
Kubernetes
is
there's
a
lot
been
a
lot
of
discussion
around
something
like
opa
gatekeeper,
sort
of
you
know,
succeeding
or
taking
over
pod
security
policies
as
an
example-
and
there
actually
have
been
you
know,
platforms
like
azure
kubernetes
service
that
have
moved
to
you
know
enable
that
type
of
work
and
that
type
of
functionality
using
opa
gatekeeper.
B
But
you
know,
I
think,
at
the
same
time
you
know
the
the
use
cases
for
opa
and
such
are
still
being
you
know
established.
I
think
we
see
a
lot
of
people
using
it
for
things
related
to
configuration,
management
and
so
on.
You
know
things
like
admission
control,
you
know,
can
benefit
from
from
opa
and
for
stack
rocks.
You
know
I'll,
let
chris
you
know
share
his
perspective
on
this,
but
you
know
for
stack
rocks.
B
You
know
we
have
a
lot
of
similar
and
shared
views
on
the
importance
of
you
know:
policy
enforcement
in
you
know
in
these
cloud
native
environments,
and
so
we've
also,
you
know,
undertaken
a
lot
of
work
that
you
know
in
the
future.
You
know
could
benefit
or
even
amplify
the
work
that
the
opa
project
makes
available,
because
we
have
you
know
rich
set
of
you,
know
70
plus
built-in
policies
and
a
way
of
applying
policies
across
the
full
life
cycle.
B
A
Yeah
and
then
there's
some
some
follow-up
questions
here
that
have
come
in
from
opi.
So
clearly,
this
is
a
pretty
hot
topic
and
you
know
with
with
opa
our
customers
generally
have
been
looking
at
it.
As
a
way
of
of
you
know,
looking
at
that
particular
silo
right,
the
the
subject
matters
that
opa
covers
are
are
kind
of
limited
to
that
deployment.
Error
and
our
philosophy
really.
A
Is
that
a
lot
of
the
things
that
you
want
to
measure
like
as
a
security
or
a
compliance
business
goal
are
going
to
be
in
in
more
than
one
silo
right.
It's
not
just
about
what
went
into
the
image
contents,
but
how
it's
being
deployed,
and
so
our
engine
here
was
really
designed
to
allow
you
to
understand
like,
for
example,
when
you
have
vulnerabilities
in
a
privileged
container
right.
That
combination
of
things,
which
is
an
attribute
of
a
deployment,
an
attribute
of
an
image
combined
in
one
policy.
A
So
you
can
get
a
little
bit
more
of
that.
That
signal
out
of
the
the
noise.
You
know
things
like
runtime
right,
which
aren't
covered
by
opa
at
all
are
a
challenge,
because
there's
a
lot
of
potential
noise
here
and
most
of
the
the
systems
that
would
measure
you
know
how
I'm
running,
containers
in
my
environment
don't
take
into
account
the
name
space
that
it's
running
in
or
whether
this
is
a
development
or
a
or
a
production
cluster.
A
So
that
context
is
what
we
focused
on
right,
where
so
we
don't
use
opa
for
that
part
of
it,
and
that
allows
us
to
combine
the
attributes
there
and
there's
a
lot
of
built-in
examples
of
policies
in
the
stack
rocks
product
that
invoke
some
of
the
controls
that
we've
talked
about
today
and
and
they
spanned
that
life
cycle.
The
other
is
that
you
know
opa
is
kind
of
frustrating
in
that
it
provides
you
with
the
feedback
as
to
what
what
happened
like
what
the
problem
is-
and
that's
that's
good.
A
A
So,
in
fact,
we
started
to
cover
some
of
these
other
questions
here.
You
know
how
we've
talked
about
the
kubernetes
attack
and
the
attack
matrix
and
you
know,
can
we
nawab
is
asking
us?
Can
we
talk
about
how
stack
rocks
can
help
identify
and
protect
some
of
those
like
do?
We
have
features
specifically
to
address
some
of
those.
The
attack
techniques
that
you
mentioned.
B
Yeah,
so
you
know
the
there's:
there's
a
lot
of
different
attack,
vectors
right,
there's,
you
know
40,
you
know
individual
techniques
and
you
know
for,
for
you
know,
details
of
those
in
a
breakdown
of
those
different
threat
vectors
and
how
to
mitigate
them.
You
know
comprehensively,
you
know
we
have
other
resources,
like
you
know,
a
series
of
blog
posts,
as
well
as
a
white
paper
on
the
topic.
We
also
have
a
recorded
webinar
from
a
couple
weeks
ago,
where
we
we
touched
on
those
things.
B
I
think
the
takeaway,
however,
for
you
know
from
the
the
matrix
overall
is
that
there
are
a
wide
range
of
different
types
of
threat,
vectors
that
you
need
to
think
about,
but
the
mitigations
can
also
also
be
common
to
several,
which
is
to
say
40.
Different
vectors
doesn't
necessarily
mean
you
need
40
different
ways
or
you
know
40
different
mitigations.
B
You
know
to
protect
yourself.
There
are
actually
a
number
of
you
know,
a
few
controls
that
have
high
value,
which
can
be
used
to
protect
against
many
of
them,
and
so
that's
even
separate
from
stack
rocks.
You
know,
and
so
I
would
say,
take
a
more
complex
attack
vector
in
the
matrix
as
an
example,
one
that
you
know
leverages
and
you
know
an
an
application
vulnerability
in
this
case.
B
You
know
what
would
happen
if
there
was
an
actual
compromise,
and
so
I
think
those
types
of
principles
you
know
which
apply
to
that
particular
technique.
It
can
be
thought
of.
You
know
throughout
you
know
many
of
the
other
threat
vectors
that
are
represented,
but
in
terms
of
how
stack
rocks
helps
you
know
in
two
regards
one
where
native
controls
can
benefit
you
or
protect
you
from
these
different
attack.
B
Vectors,
you
know,
stack
rocks,
helps,
take
the
takes
the
complexity
out
of
managing
and
configuring,
those
native
controls
and
then
in
the
second
zacrox
complements
all
you
know
those
approaches
with
things
like
runtime
monitoring
and
observing
and
detecting
you
know,
system
level
activity
that
reflects
your
particular
techniques
that
you
know
that
are
outlined
in
the
attack
matrix.
But
you
know
chris,
I
don't
know
if
you
you
want
to
elaborate
on.
You
know
the
ways
that
you
know
stack
rocks.
B
A
Yeah
my
favorite
example
of
this
is,
and
when
we
have
this
as
a
demo,
in
fact
we'll
point
to
some
resources.
If
you
want
to
see
the
stackrock's
product
and
some
of
these
attacks
live,
some
of
our
product
managers
have
delivered
these
things
in
in
recordings
and
webinars.
I
talk
about
them
in
some
of
the
the
the
sessions
that
I
do
about
handling
kate
security.
One
of
my
favorites
is
the
use
of
the
read.
Only
root
file
system.
A
A
Your
teams
understand
that
you
know
this
is
a
preventive
mechanism
and
especially
in
in
services
that
are
going
to
be
directly
connected.
Let's
say
to
the
internet
than
having
the
read-only
root
file
system
on
those
containers
enforces
that
that
you
know
immutable
nature
of
the
infrastructure
and
just
makes
these
attacks
fundamentally
impossible.
It's
it's
cool
stuff
to
watch.
A
We
have
a
few
other
questions
coming
in
here,
so
back
to
secrets
management.
Do
we
have
do
we
have
plans,
or
can
we
monitor
on
configurations
of
you
know,
non-kubernetes
secrets
managers?
I
mean
this
one
today.
I
know
that
we
don't
today
have
any
plans
for
this,
partly
because
we've
got
a
lot
to
do
with
kubernetes
and
kubernetes
secrets
are
generally
the
mechanism
by
which
those
integrations
happen.
Even
if
the
storage
and
the
source
of
it
is
is
externally.
I
don't
know
if
you
have
any
product
thoughts
on
that.
A
B
You
know,
I
I
think
I
think,
generally,
you
know
our
overall
overall
philosophy
is
that
there's
a
in
views
that
there's
a
rich
ecosystem
of
cloud
native
tooling
around
there
you
know
secrets
management
solutions
are
ones.
You
know
subset
of
that,
and
so
our
general
approach
is
to
you
know,
want
to
integrate
with
you
know,
tool
you
know,
tool,
chains
and
tooling
that
organizations
have
you
know.
B
I
do
think
we
see
a
lot
of
organizations,
utilizing
kubernetes
native
secrets,
similar
to
you
know,
but
we
have
the
same
philosophy
that
extends
to
things
like
image
scanners,
as
well,
as
you
know,
instant
response
systems,
and
so
so
so
generally,
you
know
our
view.
Is
you
know
we
like
to
integrate
with
the
set
of
tooling
that
the
ecosystem
is
out
there?
I
I
just
think
that
you
know
we
do
see
relatively
fewer
people
utilizing
these
third-party
secret
solutions.
B
But,
as
I
spoke
about
earlier,
you
know
when
the
question
came
up,
they're
very
valid
reasons.
You
know
to
consider
a
solution
like
that
if
it
suits
your
organization's
needs,
but
in
terms
of
you
know
how
it
fits
into
your
environment,
you
know,
I
think
it's
just
worth
it
worth
mentioning
generally,
that
you
know
any
any
additional.
You
know,
components
and
tooling
will
introduce
some
operational
overhead
could
also
introduce
you
know
different
points
of
know,
vulnerability
from
a
security
standpoint,
so
it's
always
worth
keeping
in
mind.
A
Great,
so
back
to
opa,
there's
some
questions
about
whether
we're
going
to
be
integrating
opa
directly
into
stack,
rocks
and
so
that
policy
and
opa
can
be
gonna
be
worked
on
from
within
within
stack
rocks
I'll
start
off.
I
think
that,
with
working
with
customers,
who've
been
using
opa.
What
we've
done
is
actually
incorporated
some
of
the
capabilities
that
opa
has
into
our
policy
engine.
So
again
we're
we're
we're
a
multi-stage.
A
You
know
multi-uh
criteria
company
here,
like
the
policies
that
we've
written
to
accomplish
some
things
like
like
isolation
of
pods
and
deployments,
or
the
intrusion
detection
that
we
do
run
across
those
different
life
cycle
stages,
and
so
the
goal
has
not
been
to
just
duplicate
what
opa
has
done
but
provide
a
better
version
of
that
you
know.
Also
managing
opa
is
again
as
a
separate
product
inside
of
the
cluster
and
again,
if
we
can
meet
the
use
cases
that
opa
is
meeting
for
you
today
in
the
product.
A
We
think
that
the
the
broader
integration,
in
terms
of
of
you
know
multi-stage
life
cycle
policies,
the
education,
the
empowerment
for
developers,
compliance
reporting,
notifications,
like
we
think
that
that's
a
you
know,
that's
a
better
way
to
approach
this.
So
if
there's
something
that
we,
you
know
that
we
didn't
do
today,
some
value
from
you
know
deployment
that
we
don't
currently
query.
A
B
Yeah,
you
know
what
I
think
the
clearest
point
where
you
know
we
are
actively
monitoring
opa,
and
you
know
you
know
thinking
through
its
implications
and
I
think
the
community
is
as
a
whole
is
you
know
how
okay
might
be
potentially
integrated
and
and
taken
advantage
of
and
leveraged.
You
know
with
regards
to
kubernetes
capabilities
itself,
and
so
when
you
consider
something
like
how
a
gatekeeper
might
be
utilized,
you
know,
as
pod
security
policies
are
depleted.
That
becomes,
you
know
a
natural
point
for
us
to
consider.
B
You
know
how
that
fits
in
with
being
kubernetes
native
and
then
that
functionality
being
a
native
part
of
kubernetes.
You
know
the
kubernetes
platform
itself
in
terms
of
you
know:
enforcing
policies
at
a
pod
level
at
a
container
level
and
so
on,
and
so
from
from
our
standpoint.
You
know.
Some
of
these
developments
with
regards
to
okay
are
extremely
interesting,
because
it's
not
really
just
about
thinking
about
policy
enforcement.
More
generally,
it
you
know
separate
from
the
communist
platform.
B
It's
really
thinking
about
how
we
can
actually
integrate
this
policy
enforcement
functionality
into
the
system
going
forward
and
I
think
that's
the
main
issue
that
the
community
has
been
thoughtfully.
You
know
sorting
through
and
so
it's
something
that
you
know
we
are
we're
actively
following,
and
you
know
looking
forward
to
seeing
the
outcome
of.
A
B
Yeah
I
mean,
I
think,
that
you
know
first,
I
think
the
gen,
the
general
trend
in
the
ecosystem
has
been
towards.
You
know
standardization
and
really
you
know,
standard
framework
and
interface
that
allows
for
the
development
of
different.
You
know
container
runtimes
and
container
engines,
and
you
know,
I
think,
that's
a
great
thing,
because
it
enables
more
choice
and
flexibility
for
customers.
Now
now
practically.
B
I
think
you
know
a
strong
consideration
in
my
opinion,
for
how
you
should
consider
what
container
runtime
you
want
to
use
is
dependent
on
what
kubernetes
platform
you
decide
to
go
with.
You
know,
for
example,
you
know
if
you're
using
red
hat
open
shift,
then
cryo
is
going
to
be
a
you
know,
natural
choice
and
that's
you
know
really
what
is
going
to
align
with
and
it's
sensible
from
a
standpoint
of
what
run
time
you
want
to
use.
I
think,
over
time,
other
platforms
will
also
you
know,
gravitate
you
know
towards
different.
B
B
So
historically
that
has
certainly
been
docker,
but
I
think
that
you
know
the
committee
has
seen
opportunities
to
you
know,
especially
for
you
know,
running
container
runtimes
that
are
a
little
bit
lighter
weight
in
some
aspects
or
don't
need
all
the
functionality,
for
instance
at
docker
packages.
You
know
to
move
to
something
like
container
d
for
instance,
and
so,
if
you
look
at
azure
kubernetes
service
there
there
is
they're.
B
You
know
they're
further
along
in
terms
of
moving
towards
container
d
as
a
default
runtime,
and
so
I
think
that
should
be
a
starting
point
for
how
you
think
about
what
run
time
to
use.
I'm
not
saying
that
should
be
determinative,
but
you
know
it
should
definitely
be
a
strong
consideration,
because
you
do
want
to
ensure
that
the
runtime
engine
you're
using
is
going
to
be
fully
supported
and-
and
you
know,
by
the
platform
or
distribution
that
you're
using.
A
Great
the
next
one
is
another
different
one
here
about
the
kubernetes
dashboard.
This
is
the
the
administrative
gui
that's
provided
with
kubernetes
part
of
the
cncf,
it's
part
of
kubernetes,
but
it
is
often
a
vulnerable
component.
So
josephine
is
asking
about
security
and
recommendations
that
we
have
for
for
kubernetes,
dashboard.
B
Yeah,
I
think
you
know
I
actually
think
the
an
important
starting
question
or
valuable
starting
question
with
regards
to
the
kubernetes
dashboard.
Is
you
know
why
you
might
want
to
enable
it?
In
fact,
you
know
a
lot
of
the
platforms
nowadays.
Actually
disable
it
by
default
or
don't
deploy
it
and
stack
rocks
actually
has
a
policy
to
alert
if
the
dashboard
is
in
fact
deployed
and
running,
and
the
reason
for
that
is
the
you
know.
Historically,
the
dashboard
has
been
a
point
of
vulnerability
for
cluster
compromise.
B
There
have
been
examples
out
there
and
it's
actually
one
of
the
techniques
specifically
described
in
the
attack
matrix,
where
you
know
as
an
example,
one
of
the
ones
that
disclosed
stories
was
you
know,
tesla
was
running
a
kubernetes
environment
and
was
compromised.
You
know,
via
the
the
kubernetes
dashboard
which
allowed
attackers
to
accomplish
crypto,
cryptocurrency,
mining
and,
and
the
reason
for
that
is,
you
know
partly
of
the
way
you
know
the
settings
that
were
used
when
the
dashboard
is
sort
of
like
disa
deployed
by
default.
B
So
if
for
if,
for
some
reason,
you
really
need
to
deploy
the
dashboard,
which
we
would
not
recommend,
but
if
you
did
want
to
deploy
it,
then
it's
really
important
to
ensure
that
you
limit
network
access
to
it
and
a
lot
of
these
compromises
that
involve
the
dashboard.
The
dashboards
were
exposed
publicly
to
the
internet
and
separately.
You
want
to
ensure
that
privileges
on
the
dashboard
are
restricted
again.
B
A
Yep,
that's
been
one
of
our
standing
recommendations
and
I
agree
that
it's
actually
generally
got
a
cluster
admin
service
account
on
that
deployment,
and
that
creates
a
risk
because
that
dashboard
really
does
have
the
ability
to
to
administer
the
entire
environment,
including
destroy
the
cluster
and
access
data
on
other
nodes
and
and
on
the
services.
So
we
generally
strongly
recommend
against
running
it,
especially
in
a
production
environment,
but
if
you
do
need
it,
some
of
those
restrictions
that
we
recommend
on
on
a
lot
of
applications
would
have
would
apply
here.
A
So
thank
you
for
that
question.
I
guess
we
can't
avoid
this
one,
because
there's
a
few
questions
now
stacking
up
here
about
istio
in
general,
about
about
the
surface
mesh
topic
in
general
and
ingress
controllers:
do
we
incorporate
any
of
these?
Do
we
recommend
any
of
them?
What's
our
current
support
and
istio
comes
up
here
a
lot,
but
I
suppose
that
question
could
be
directed
at
any
of
the
service
mesh
technologies.
B
So
I
sort
of
think
the
first
one
in
terms
to
start,
which
is
which
one
you
know,
which
ones
we
integrate
and
support.
You
know
today
as
an
example,
we
provide
visibility
into
istio,
including
seo
services
that
are
running
and
part
of
that
part
of
that
reason.
Why
I
start
with
istio
is
that
you
know
you
know
issues
built
on
kubernetes.
It
has
dependencies.
You
know
in
kubernetes,
via
custom
resource
definitions,
you
know,
and
so
I
think
it's
aligned
significantly
with
the
overall
direction
of
kubernetes.
B
Of
course,
there
are
other
considerations
that
may
lead
you
to
a
different
service
mesh,
but
I
think
one
of
the
the
key
considerations.
You
know
some
of
the
key
considerations
worth
keeping
in
mind
when
you're
thinking
about
service
mesh
or
thinking
about
the
particular
use
cases
you
want
to
accomplish
via
service
meshes
typical
ones.
We
see
are
ones
related
to
authorization,
and
so
that's
another
one
where
we
feel
istio
has
a
very
rich
framework
for
authorization.
Originally,
it
started
as
role-based
access
control
and
so
more
something
more
holistic
based
on
authorization.
B
A
Right
and
answer
the
the
functionality
questions
here,
they're
part
of
that
stack,
rocks
works
with
all
of
these.
We
don't
have
a
strong
opinion
just
yet,
and
you
know
that
anyone
is
better
for
security.
It's
really
about
what
your
application
requires
and-
and
you
know
what
infrastructure
features.
You're
looking
for
our
product
here,
the
the
kubernetes
security
product
works
with
all
of
them
right
that
aco
and
and
linker
d
and
others
are
all
supported
platforms
that
that
will
work,
and
we
can
provide
that.
A
We
provide
security,
support
and
kubernetes
natively
there.
The
next
question
here
is
actually
a
follow-up
to
our
our
topic
about
you
know
about
our
back
and
and
about
cluster
admin
credentials,
because
I've
noticed
a
few
spots
where
you
know
everybody
on
the
user
team
has
cluster
admin
credentials
and
you
know,
applications
like
helm,
tiller
in
in
v2,
and
things
like
argo,
cd
and
even
prometheus
will
often
have
cluster
admin
credentials.
So
how
can
we
tamp
that
down?
B
Yeah,
I
think
you
know
it
is
worthwhile
to
separate
out
authentication
from
authorization
right
and
our
our
back
is
really
about
authorization.
You
know
on
on,
and
some
of
this
will
vary
depending
on
the
environment.
You
know,
particularly
if
you're
focused
on
authentication
and
you're
running
cloud
you're
going
to
look
at
cloud.
You
know
identity
and
access
management
services,
but
I
think,
with
regards
to
our
back,
you
know
one
of
the
ways
that
we
see
people
effectively.
Managing
you
know
some
of
this
complexity
or
or
role
management
around.
B
Our
back
is
to
think
about
a
you
know,
set
of
baselines
for
particular
roles,
because
kubernetes
has
a
lot
of
different
capabilities
that
are
intended
to
make
our
back
more
flexible.
There
are
features
like
roll
aggregation
and
then
also
you
can
easily.
You
can
easily
end
up
with
a
lot
of
overlap
in
role
definition
and
so
the
problem
with
those
things
or
or
so
the
downsides
of
those
things.
If
they're
not
managed
appropriately
is
it
can
lead
a
lot
to
a
lot
of
complexity,
and
so
you
may
not.
B
You
know
you
may
inadvertently
grant
access
for
a
user
or
service
account
that
you
don't
intend
to.
It
also
becomes
difficult
if
you're
looking
to
de-provision
or
d
scope,
privileges,
and
so
our
general
recommendation
typically
is
to
start
with
sort
of
a
baseline
definition,
and
then
you
know
add
either
incremental.
You
know,
add
incrementally
from
there.
So
you
better
understand
kind
of
the
full
scope
that
any
given
user
or
service
camp
has
now.
B
I
think
you
can
then
take
those
baseline
roles
easily
and
map
them
to
roles
assigned
via
your
existing
identity
management
solution,
which
might
you
know
ldap,
ad
cloud
im
or
or
whatever
it
might
be.
But
you
know
I
think,
that's
a
more
general
approach
without
knowing
the
specifics
of
how
you
might
think
about
configuring
and
managing
role-based
access
control.
So
so
it
can.
It
can
lead
to
issues
and
we've
seen
it
before
where
the
arbex
is
a
good
thing,
but
it
can
also
get
complex
very
quickly.
A
Yeah
and
we
have
a
great
webinar
and
an
article
on
our
blog
site
that
covers
this
topic.
It's
called
top
five
are
back
mistakes
and
it
talks
about
things
like
the
cluster
role,
aggregation
and
role
aggregation
and
what
happens
when
you
use
some
of
those
features
and
some
of
the
built-in
roles
that
inadvertently
grant
additional
privileges.
A
A
Another
topic
is
building
the
right
rules
and-
and
we
notice
that
a
lot
of
I've
seen
this
on
a
lot
of
open
source
projects
that
provide
a
cube
deployment.
They'll,
say:
hey,
create
a
service
account
and
grant
it
cluster
admin
role,
and
that's
because
it's
easy
to
do
that
and
it
makes
the
product
work
right
and
not
get
those
pesky.
You
know
permission
denied.
There
are
some
open
source
tools
around
this.
A
You
know
one
of
the
things
that
we've
looked
at,
that
I've
looked
at
and
had
some
customers
playing
around
with
are
some
tools
like.
I
think
it's
audit
to
our
back
that
actually
take
a
look
at
your
coupe
audit
logs
to
try
to
understand
you
know
what
kind
of
permissions
your
users
are
actually
using,
so
that
you
can
restrict
to
to
better
our
back
roles
right
instead
of
giving
them
cluster
admin.
A
So
there
is
a
question
here
we
are
getting
to
the
end
of
our
time,
but
we'll
have
a
couple
more
minutes.
Left
for
kubernetes
monitoring,
so
this
is
a
different
topic.
What
do
you
think
about
prometheus
or
grafana
from
a
security
observability
standpoint?
Are
these
tools
just
reactionary,
or
can
they
be
proactive.
B
Yeah,
I
think
it
depends
on
what
type
of
you
know,
cluster
monitoring,
you're
looking
to
accomplish.
First
of
all,
you
know,
is
it
more
about
you
know,
say
like
resource
resource
and
performance
monitoring,
or
is
it
about?
You
know
security
monitoring,
because
I
think
that
you
know
could
definitely
lead
you
down
different
paths.
You
know
I,
I
think,
with
respect
to
security
monitoring
to
start,
you
know
specifically.
B
B
Every
single
container
and
pod
is
executing
within
the
environment
and
and
the
reason
for
that
is
that
any
type
of
anomalous,
malicious
or
otherwise
security,
relevant
activity,
that's
going
to
happen
is
going
to
happen
at
the
level
you
know
of
individual
containers,
and
you
want
to
be
able
to
understand
that
at
a
more
granular
level.
So
you
can
diagnose.
B
You
know
the
root
cause
of
that
particular
security
issue
or
that
you
know
unexpected
behavior,
and
so
you
know
that's
something
that
stack
rocks.
Does
you
know
we?
We
implement?
You
know
like
crystal
elaborate,
but
you
know
we
implement
runtime
monitoring
at
the
system
at
a
system
level,
but
I
would
say
more
broadly,
for
you
know,
monitoring,
that's
relevant
to
you,
know,
resources
and
performance.
B
Generally,
I
think
prometheus
is
certainly
one
that
makes
sense
to
consider
it's
a
cncf
project,
and
you
know,
I
think,
generally
there's
a
lot
of
benefits
to
aligning
with
these
projects
that
the
community
is
continuing
to
support
and
advance
and
a
lot
of
benefits
in
terms
of
you
know,
integration
and
and
how
it
fits
in
with
your
kubernetes
to
consider
as
well,
but
I
think
from
a
security
standpoint.
You
know
these
are
certainly
not
enough.
A
Yeah
imagine
my
experience
with
customers
in
the
field.
I
think
they're
companies
that
are
startups
they're
born
in
the
cloud
they're
only
running
kubernetes,
prometheus
and
grafana
have
been
a
natural
choice
and
and
they're
using
it
for
generally
observability
of
performance,
metrics
but
large
organizations.
I
think
the
choice
of
tools
for
that
is
going
to
depend
more
on
on
the
kinds
of
things
you
know
existing
tooling
and
existing
infrastructure
that
you
might
want
to
incorporate.
Under
the
same
guys.
A
A
So
I
think
we've
answered
most
of
the
questions
here.
If
we
have
missed
anything
we'll
get
back
to
you
we'll,
you
know
reach
out
to
you
and
try
to
provide
an
answer
or
thoughts
on
all
of
these
things.
We
have
one
last
pulse,
we're
going
to
put
that
up
on
the
screen
here
before
we
depart
and
ask
you
a
little
bit
more
about
like
where
your
security
priorities
lie.
A
I'd
also
like
to
take
this
opportunity
to
thank
everybody
again
for
for
joining
and
if
there's
something
interesting
here
that
we
didn't
get
to
that
you'd.
Like
a
you
know,
a
personalized
demonstration
you
know
feel
free
to
reach
out
to
us
as
part
of
our
our
outreach
respond
back
to
us
we're
delighted
to
get
you
a
demo.
Show
you
what
this
can
do
in
your
environment
answer
your
questions.
A
That
probably
will
be
me
or
my
team.
So
you
get
you
get
access
to
the
folks
here
at
stack,
rocks
who
can
could
fill
you
in?
We
also
have
some
other
resources
that
we'll
send
out.
We
did,
as
you
know,
see
some
questions
here
of
things
that
we've
actually
got.
Demos
for
we've
got
articles
on,
and
the
stackrocks
blog
is
a
great
resource
center
for
that
stuff.
A
Great
well
vulnerability
management,
always
the
solid
base
of
all
the
responses
here.
Quite
a
few
talking
about
network
segmentation
and
and
runtime
threat
detection.
That's
great!
It's
good
to
see
that
teams!
You
know
concerns
match
hours
in
general,
the
the
the
priorities
I
see
here
match
kind
of
you
know
every
one
of
my
customers
priorities
and
what
we're
we're
tackling
in
order.
A
So
unless
there's
any
last-minute
questions
here
that
we
can
quickly
answer,
I
want
to
thank
everybody.
We'll
draw
this
to
a
conclusion.
As
we
mentioned,
this
will
be
on
a
recording,
and
so
we
can,
you
can
enjoy
the
conversation
not
so
live
the
next
time.
We'll
also
follow
up
with
all
of
the
the
unanswered
questions,
and
you
know
some
of
the
resource
materials
that
we've
hosted
as
part
of
it
wayne.
It
was
a
real
pleasure
thanks
again.