►
From YouTube: OpenShift Commons Briefing #99: Automated App Defense on OpenShift with Michael Withrow
Description
The very nature of containers – their minimalistic, declarative, and immutable characteristics – provide an opportunity automate and scale the protection of apps that run within them. In the old world of security, developers needed to manually tell security teams how their app worked and security teams needed to manually configure various tools, like firewalls, IDS/IPS, and vulnerability management suites, to protect them. Invariably, as the apps changed over time, the rules got out of sync and many organizations fell back to basic, parameterized approach to security. With continuers, though, we can apply machine learning to automatically build a predictive runtime model for each unique version of every app you have, helping you both improve your active threat protection but also to do so much more efficiently. In this briefing,Michael Withrow discusses how Twistlock uses these fundamental container characteristics to block vulnerabilities, stop malicious behaviors, and filter app layer traffic, fundamentally change how organizations secure their apps in a cloud native stack.
A
Well,
hello,
everybody
and
welcome
again
to
another
openshift
Commons
briefing,
this
time
with
the
open
ship,
Commons
longtime
members
twistlock
is
going
to
talk
about
automated
app
defense,
defending
your
applications
on
OpenShift
and
we
have
Michael
Withrow
with
us
from
twistlock
who's
been
giving
us
talks
before
so
I'm.
Looking
forward
to
this
one
and
I'm
gonna,
let
Michael
take
it
away,
we'll
do
live
Q&A
in
the
chat.
If
you
have
questions,
please
ask
them
and
we'll
try
and
answer
them
and
then
we'll
have
live
Q&A
at
the
end.
B
B
For
attending
really,
the
idea
here
is
to
walk
everybody
through
twistlock
and
what
we
do
as
a
product
as
we're
going
through
all
right,
and
so,
as
you
start
out,
you
know
what
is
twistlock.
So
really
as
you
look
at
from
a
capabilities
point
of
view,
we
provide
automated
lifecycle
base
security
from
beginning
of
the
lifecycle
all
the
way
through
the
end.
So
irregardless
of
well
as
you
look
at
the
entire
docker
ecosystem
as
we
go
across
all
the
different
industries,
all
the
different
Geo's,
you
see
representation
across
the
entire
ecosystem.
B
We
have
many
customers
running
Jenkins.
Many
customers
run
in
bamboo
circle,
CI
drone,
bitbucket
teamcity,
all
from
a
CI
perspective,
so
we
have
many
capabilities
to
integrate
there
so
think
about
it.
Is
automated
integration
and
the
build,
and
not
only
alerting,
on
the
capabilities
on
build
button,
be
able
to
restrict
those
builds
based
off
phone
abilities,
state
threats,
state
governance,
state,
those
kind
of
things
like
that
I
mean
as
we
move
forward.
You
know.
B
Obviously
we
get
into
the
CD
portion
of
the
conversation
that
image
gets,
that
artifact
gets
moved
upstream
into
a
registry
out
for
deployment
once
again,
there's
a
myriad
of
tools
that
exist
from
a
registry
perspective.
You
know
whether
it's
any
one
of
the
like
clouds,
you
know
from
Google
or
Amazon
or
AWS,
any
private
ones,
docker
DTR,
artifactory,
Nexus
Quay.
You
know,
as
you
look
from
the
OpenShift
registry
and
those
particular
perspectives
like
that
as
you're
getting
through
and
then,
of
course,
from
a
deployment
perspective
as
you're
kind
of
going
through.
B
Obviously,
this
is
very
focused
on
on
openshift
an
option
to
regard
you'd
have
an
open
shift
cluster.
You
know
on-premises
multi-tenant,
in
whatever
it
might
be,
having
the
ability
to
go
and
deploy
into
there
at
your
edge
you're
kind
of
going
through,
which
is
really
the
the
premise
of
what
we're
gonna
talk
about
today,
as
we're
going
through
and
so
skip
through
these,
as
we
kind
of
go
through
really.
B
As
you
look
at
it
from
a
product
perspective,
we
really
focus
off
of
a
couple
of
key
areas
as
you're
going
through
the
base
of
the
product
and
where
we
started
out
is
with
an
access
control
mechanism,
and
there
is
some
some
overlap
with
the
with
the
OpenShift
capabilities
there.
I
will
talk
about
that
as
we
go
a
little
bit
forward
off
from
that's
a
good
point.
But
then,
as
you
move
up
the
stack,
you
can
see
that
we
have
compliance
capabilities.
Really.
B
Those
governance,
those
industry,
governance,
settings,
think
CIS,
think
nist
think
PCI
HIPAA
sauk
those
kind
of
things
like
that
when
I'm
talking
compliance,
we
have
all
the
vulnerability.
Data
like
I,
said
not
just
vulnerability
but
also
threat
data,
so
we're
kind
of
moving
up
and
then,
as
you
people
airing
on,
then
we
bring
in
you
know
a
defense
in
depth.
Runtime
defenses,
as
well
as
we're
kind
of
going
through.
B
So,
as
you
go
from
static
content
over
to
metadata,
essentially
introduce
additional
threat
protection,
vectors
against
those
different
attack
surfaces
and
then
rounding
it
out
with
cloud
native
firewalling
capabilities
that
I'll
talk
through
as
we're
going
through,
and
so
with
that
I'll
kind
of
get
into
the
architecture
and
then
I'll
kind
of
break
it
down.
I,
know
after
you
get
in
the
product
and
show
it
through,
and
so
how
we
do.
B
All
of
this,
like
I,
said
automatic
automatic
is
the
really
the
key
term
is
you're,
looking
through
from-from
capabilities,
point
of
view,
at
the
rate
of
change
that
containers
really
bring
into
the
marketplace,
there's
really,
no
matter
how
many
bodies
you
throw
at
it.
There's
really
not
enough
manual
process
that
you
can
kind
of
use
to
get
in
front
of
this,
so
so
automatic
is
the
key
way
and
how
we
do
this
is.
We
are
just
a
set
of
containerized
technology
ourselves
as
you're
kind
of
going
through.
B
You
can
see
the
console
here,
which
is
really
just
the
front
end
of
the
product.
It's
where
you
basically
set
in
policy
where
you
look
at
the
audit
data,
it's
where
the
CVE
data
gets
pumped
into
the
environment,
it's
where
your
building
and
all
your
alerting
notifications
right
so
as
you're
kind
of
going
through.
Maybe
you
know
you
want
to
kick,
maybe
you
have
an
existing
slack
channel
or
JIRA
ticketing
or
pager
duty,
or
something
like
that.
B
You
have
all
your
directory
users
coming
in
through
octa
or
ad,
or
something
like
that,
and
then
your
natives,
Splunk
users
or
sumo
logic,
or
you
know
cloud.
You
know
anything
on
one
of
the
cloud
vendors
as
you're
kind
of
going
through
have
an
ability
to
do
native
syslog
integration
as
you're
going
through
and
really
as
you
look
at
that.
That's
the
front
end
a
singular
entity.
We
have
some
h8
capabilities.
B
Obviously
the
ability
we
provide
an
ammo
file,
so
you
can
deploy
that
right
into
open
shift
and
so
open
shift
will
manage
the
H
a
of
the
console
as
you're,
going
through
with
the
PV
and
obviously
IBM
will
file
for
the
PV
and
all
that
kind
of
stuff
like
that
which
I'll
talk
about
in
a
second.
As
you
kind
of
scale
those
things
out,
then
the
point
of
enforcement
is
really
downstream
in
all
the
different
nodes.
B
So,
depending
on
how
you
build
out
your
open
shift
cluster
right
so
most
of
the
time
on
an
open
shift
cluster.
All
the
masters
are
not
open
for
scheduling
right
as
you're
kind
of
going
through,
but
all
your
downstream
infra
and
app
nodes
across
your
different
cluster,
that's
typically
opened
up
for
for
scheduling
where
the
pods
you're
gonna
actually
get
deployed.
B
But
that's
really
the
first
point
so
that
that
defenders
is
gonna,
be
appointed
presence
on
that
particular
node
asked
as
pods
or
deployed
on
to
that
node.
It's
gonna
build
the
baseline,
build
the
state,
get
all
the
configuration
data
and
then
basically
now
it's
a
life
cycle
based
conversation.
What's
the
drift
off
of
that
base?
What's
the
drift
off
of
that
state
as
you're
going
through?
B
So
that's
where
the
defender
really
becomes
a
critical
part
of
the
of
the
architecture
to
really
define
that
that
configuration
and
then,
as
I
alluded
to
before,
we
also
have
the
ability
to
extend
well
down
into
this
CIC
the
pipeline
process
Ryan.
So
with
plugins
with
we
have
an
independent
tool
called
a
twist
CLI
so,
depending
on
what
you
might
be
leveraging
from
a
CI
perspective.
Obviously,
an
open
shift,
you're
running
Jenkins
pipeline
base
capabilities
and
Jenkins.
B
That's
a
native
capability
for
us,
which
I'll
show
as
we
kind
of
get
through
it
as
we're
going
a
little
bit
deeper
and
then
you
know
you're
open
shift
register.
You
have
the
ability
to
plug
in
your
open
chef
registry.
You
know,
depending
on
how
your
topology
is,
there's
some
open
shift.
Customers
I
have
a
nexus
front-end,
which
is
wide
open
to
the
Internet.
We
have
the
ability
to
plug
in
there,
so
the
developers
pull
resources
into
there.
B
We
can
start
to
build
the
state
of
the
images
in
that
nexus
registry
for
they're
brought
into
the
open
ship
registries
inside
the
cluster.
Whatever
that
topology
might
look
like,
we
have
a
lot
of
different
ways
to
plug
into
into
those,
because
we
are
agnostic
from
from
agilent
footprint,
and
so
so
with
that
what
I'll
do
is
now
I'm
going
to
get
out
of
the
presentation,
side
and
I
will
go
through
and
really
kind
of
get
into
the
product
as
we're
going
through
all
right.
B
So
we
bring
this
over
and
maximize
this
out,
and
so,
as
you
look
at
it,
the
key
things
to
really
understand
is
that
as
you
as
you
look
at
here's
the
front
end,
and
so
as
you
look
at
those
defenders,
I
was
talking
about
before
the
defenders
being
installed
across
the
environment
is
what's
really
starting
to
build
out
your
baseline
as
you're
going
through.
So
I
can
see
here's
the
baseline
of
my
running
containers
as
I
can
see.
As
I
looked
through.
You
know,
I
could
see
which
ones
are
internet
connected.
B
Put
in
your
you
know,
customer
not
you
know,
OSC
dot
registry,
whatever
that
might
be
you're.
Gonna.
Add
that
in
there
and
then
whatever
your
credentials
are
in
order
to
get
into
that
registry,
you're
gonna
define
it
there
as
you're
going
through
and
then
so
from
that
point,
as
as
images
are
built
or
stuffed
in
the
registry.
B
So
what
I
have
here
is
a
real
simple
pipeline
base
bill
to
kind
of
show
the
configuration
as
we're
going
through.
But
the
idea
is
that
you
know
this
is
just
a
real,
simple
build-out,
but
it
shows
the
flow
is
that
somewhere,
no
matter
how
simple
or
complex
that
build
process
is
somewhere
is
an
artifact
of
actually
doing
a
docker
build
right
to
be
fair
enough.
B
It
could
be
a
docker
pool,
but
at
the
end
of
the
day
there
is
an
image
artifact
that
we're
looking
for,
and
we
are
typically
the
next
step
to
go
through
and
scan
that
that
particular
image
as
it's
moving
through
the
pipeline
right.
So
like
said
an
on
build
capability
that
we're
going
through.
So
now,
as
you
look,
there's
a
couple
of
real
key
things
that
are
really
really
important
as
you're
kind
of
going
through,
and
you
kind
of
see
here.
A
couple
of
different
warns
that
we
have
here.
The
bass.
B
Maybe
I,
want
to
warn
on
high
or
critical
only
right
as
an
example,
maybe
I'm
worried
about
all
so
I
want
to
do
low
is
an
example
or
whatever
that
is
I
can
set
that
up,
and
so
obviously
there's
any
low
vulnerabilities
in
there
we're
gonna
trip
that
entire
build
and
kick
that
back
to
the
developer,
to
remediate
all
those
low
based
vulnerabilities
Warren.
This
allows
me
to
get
that
state
know.
What's
going
on
so
I
can
move
it
up
and
depending
on
how
I
want
to
build
that
pipeline.
B
We
give
you
the
flexibility
to
tune
that,
to
whatever
you
need
and
what's
really
unique
here,
is
that
we
also
do
the
same
thing
on
the
governance
side
right.
So
obviously
we're
talking
about
governance
from
an
image
perspective,
because
there's
not
any
metadata.
All
those
kind
of
things
like
that
so
think
C
is
benchmarks
which
I'll
talk
about
in
a
second
and
only
a
couple
minutes
as
we're
going
through,
but
really
there's
a
base
set
of
confines.
That
really
say:
hey
look
on
an
image
best
practices
is
running
as
root
SATCOM
profile.
B
You
know
those
kind
of
things
like
that
really
is
a
base
layer
as
I'm
building
that
image.
Obviously,
in
a
static
level,
what
governance
settings
would
trip
up
if
I'm,
trying
to
deploy
this
into
a
PCI
environment
or
a
sock
or
a
hippo
or
whatever
it
might
be
type
of
environment
downstream.
So
you
have
a
lot
of
control
for
how
you
would
affect
that.
We
have
some
customers
that
block
on
CI
but
allow
on
C.
B
B
The
Jenkins
plug-in
has
those
same
set
of
binaries
right,
so
the
experience
is
the
same
and
what
we're
really
talking
about
from
the
capabilities
point
of
view
is
that
anywhere
across
the
lifecycle,
where
an
image
can
actually
live,
we
have
the
ability
to
plug-in
from
a
binary
level
and
could
perform
a
static
analysis
off
of
that
image
as
we're
going
through,
and
so
so,
as
you
look
at
it.
What
we're
really
talking
about
when
we
talk
about
that
static
analysis?
B
Is
that
as
we're
going
through,
we
really
look
like
set
depending
on
the
state
of
the
image.
We
really
look
at
it
from
two
different
perspectives.
You
know
this
image
on
this
particular
build.
You
know,
did
have
a
couple
of
compliance.
It
like
said
it
was
running
a
route
as
an
example
just
to
kind
of
show
a
couple
different
flavors
in
there.
You
know
just
a
simple
health
check,
based
violation
that
exists
there,
but
obviously
these
could
take
many
different
forms,
but
just
to
kind
of
show
as
a
base
layer.
B
B
As
you
look
through
it
now,
we
have
all
the
base
vulnerabilities
that
exist
here
right
as
we're
going
through,
and
so
all
the
different
details
are
gonna
be
displayed
back
to
the
developer.
So
if
you
warned
that
build
or
you
filled
that
build
off
the
developer
would
know
why
that
build
was
failed
off
right
and
what
remediation
steps
are
need
to
be
taken
place
in
order
to
move
that
build
upstream
as
you're
going
through,
and
so
as
you
look
at
that
a
little
bit
deeper.
B
That's
on
a
node
is
out
of
your
openshift
cluster
right,
so
what
we're
talking
about
is
ability
to
affect
what
images
can
actually
get
propagated
in,
but
now
a
clean
image
is
got
to
put
it
in
your
environment
and
now
vulnerabilities
exist
right.
What
kind
of
happens?
How
do
we
notify
that
there
that's
coming
through,
and
so,
as
you
look
at
it,
we
break
that
process
down
a
little
bit
deeper.
What
you're
really
looking
at
is
as
we
get
into
here
I'll.
Let
me
click
that
off.
Why
is
that
not
clicking
sorry
about
that?
B
There
we
go
just
being
a
little
slow,
sorry
about
that
as
we
kind
of
go
through,
and
so
what
we're
really
talking
about
is
that
from
a
static
perspective,
the
first
part
of
the
conversation
is
that
we're
going
through
here
and
clicking
on
the
layers
right
and
so
with
the
layers
is:
that's
really
where
we
start
out
from
a
static
analysis.
Perspective
is
really
going
through
and
say:
hey
look!
You
know
this
image
has
23
layers,
it's
basically
right
at
about
a
gig
as
I'm
going
through.
B
B
B
If
there's
any
questions,
please
just
jump
in
and
interject
on
the
questions
that
is
kind
of
going
through
and
I
will
say
that
right
now
my
console
is
not
running
on
the
dashboard,
but
let
me
show
you
something:
my
dashboard
is
not
running
on
openshift,
but
I
do
have
an
open
shift
node
here
and
then
a
couple
of
things
that
we
have
so
I
didn't
have
a
chance
to
build
it
up
before
we
got
finished
out
but
you'll
see
here.
Let
me
back
up
and
kind
of
talk
through
the
actual
deployment.
B
If
that
makes
sense,
then
I'll
circle
back
to
the
actual
vulnerability
stuff
that
we're
doing
yeah
perfect.
So
so,
if
we
catch
up
right.
So
what
we're
talking
about
is
that
as
we
go
through,
the
console
is
going
to
be
the
first
thing
that
you're
going
to
actually
actually
the
ploy
as
you're
kind
of
going
through,
and
so
the
first
real
requirement
that
we
have
is
obviously
a
persistent
volume.
B
B
Obviously,
the
important
part
about
this
is
by
default
host
path.
Implementation
is,
is
set
to
restricted,
though
there's
a
couple
of
different
ways.
You
can
do
that.
We
actually
have
the
logic
inside
of
our
gamma
file
to
actually
build
out
an
SCC
to
relax
the
host
path,
implementation
setup,
which
I'll
show
you
in
a
second,
but
depending
on
this
you're
gonna,
set
your
host
path
of
where
the
pv
is
actually
gonna.
B
Be
mounted
and
then
from
out
your
perspective,
then,
as
you
go
through
so
now,
I'm
gonna
do
an
OC
get
pv
and
you
can
see.
Oh
I
got
a
I
got
a
set,
my
config
file
so
as
I
go
through
so
I'm
gonna
do
sudo
su
for
about
prospectives
one
or
two
OC
get
pv
from
after
the
perspective,
and
you
can
see
here
that
we
have
a
twist
lock
PV,
that's
bound
right
from
a
perspective,
so
I
can
do
an
OC
describe
pv
twist
lock.
B
From
my
perspective,
you
can
get
further
details
about
how
that's
actually
set
up,
which
all
that
was
defined
in
the
in
the
gamma
file
that
was
built
there
and
then
once
that's
there.
As
you
look
through
the
next
thing
we
have
is
essentially
the
twist
lock
console
by
camel.
So
as
you
look
at
this
twist,
lock
console
off
mom
as
we're
going
through
you'll
see
here
a
couple
different
things.
We
have
a
config
map
which
is
really
the
docker
file.
B
That's
going
to
be
built
for
the
image,
which
is
all
the
the
constructs
for
the
the
twist
lock
console
itself
around
the
port
structure.
All
that
stuff,
like
that
and
as
you
can
see
in
here
as
we're
going
through
a
couple
of
the
key
things
depending
on
how
the
names
namespaces
are
constructed,
do
we
need
to
build
services
and
routes
and
all
that
kind
of
stuff
like
that.
B
If
you
deployed
the
console
and
the
defenders
in
the
same
namespace,
you
don't
really
need
to
think
about
services
and
torts
and
all
that
kind
of
stuff
like
that.
But
if
you
do
depending
on
what
your
business
criteria
is,
do
need
to
segment,
we
provide
those
services
and
port
examples
in
the
config
file
as
you're
going
through
and
then,
as
I
alluded
as
well.
B
We
actually
build
out
an
SCC
for
you
on
security
context,
constraint,
file,
name
twist,
lock,
console
and
you'll
see
that
the
first
thing
it
does
is
it
toggles
the
basically
allow
host
der
volume
plug-in
to
true,
because
there's
a
base
layer
inside
of
OpenShift
the
restricted
the
restricted
SCC
is
going
to
be
kicked
in,
which
has
basically
the
volume
plug-in
set
to
false
right.
So
essentially,
there's
a
couple
different
ways:
you
can
relax
it.
B
The
the
Leafs
prove
the
least,
the
least
intrusive
way
is
to
create
an
SCC
around
that
or
you
can
just
modify
restricted,
which
I
wouldn't
recommend
as
you're
kind
of
going
through.
So
that's
essentially
the
reason
we
build
this
out
as
you're
kind
of
going
through,
we
don't
run,
we
don't
run
as
privileged
those
kind
of
things
like
that.
The
console
is
the
least
privileged
container
as
you're
kind
of
going
through.
B
So
really,
the
host
path
is
really
the
only
thing
that
you
kind
of
kind
of
worried
about
as
you're
setting
that
and
we
do
specify
that
inside
of
the
ammo
file
as
you're
going
through,
and
so
so
as
you
look
at
it
as
we're
going
through
you
now,
you
see
the
claim
and
that
label
becomes
really
important,
as
you
saw
back
in
the
PV.
Here's
where
the
PVC
actually
is
which
allows
that
to
actually
be
bound
as
we're
going
through,
and
so
from
that
perspective,
then
you'll
see
the
base
port
structure.
B
If
you
need
to
do
it
there
off
and
that
that
particular
point
as
you're
going
through
those
are
really
the
big
things
that
you
have
as
we're
kind
of
going
through
you'll
see
the
data
volume
there.
We
do
specify
all
of
this
stuff
depending
on
what
the
registry
is,
if
you
know
typically
on
an
open
ship
deployment
everybody's
using
their
open
ship
registry.
B
So
the
exercise
is
it's
taken
the
the
image
for
the
console
putting
in
the
open
ship
registry
and
then
specifying
the
path
for
it
here
in
the
in
the
demo
file
as
you're
going
through,
and
so
as
we
go
through
the
idea
there
from
from.
Actually
the
point
is
that
now
we
can
actually
run
the
mo
files
were
going
through.
I
did
run
into
a
problem
with
that,
but
just
kind
of
give
you
a
base
example
as
we're
going
through
that's
what
I
was
working
through
some
permission
stuff
on
the
back
end.
B
That's
why
I
was
I
was
really
close
to
having
it
up
and
running.
I
apologize
for
the
actually
spective.
Here
is
my
basically,
my
openshift
clusters
were
kind
of
going
through
and
then
Alan
a
particular
perspective.
I
do
have
the
console
running
off
the
mo
file.
I
just
had
some
syntax
problems.
I
didn't
quite
get
a
chance
to
flush
out
before
this
particular
briefing
is
going
through,
but
that's
the
first
thing,
as
you're
kind
of
going
through
to
have
that
base
set
up
and
then
get
the
console
deployed.
B
B
Once
you
have
the
console
deployed
we
have
now.
The
next
thing
is
to
build
out
the
build
out
the
daemon
set
as
you're
going
through,
and
so
you
can
see
here.
We
have
a
couple
of
different
ways
so,
depending
on
how
you're,
depending
on
what
your
network
topology
is
all
stuff
like
that
you'll
build
this
out
here,
which
really
says:
hey
look
which
which
resource
you
know.
What
is
the
the
networking
connectivity
for
how
the
defenders
are
going
to
connect
back
to
the
console
as
you're
going
through?
B
So
you
would
define
all
this
out
as
you're
going
through.
Typically,
what
I
usually
always
tell
it
tell
customers
to
do
is
as
you're
going
through.
I
want
to
do
an
OC
get
SVC
right,
that's
a
respective
and
then
I'm
gonna
grab
that
cluster
IP
from
that
to
the
respective
I'm
gonna
grab
that
I'm
gonna
go
in
the
twistlock
console,
I'm
gonna,
add
a
row
rights
my
perspective
and
then
add
that
and
then
now,
as
I
do
my
deployment.
B
If,
if
it's
an
open
chief
registry,
that
typically
means
that
you
need
a
secret
to
communicate
with
it
right,
and
so
that's
one
of
the
things
we
defined
in
the
config
file
as
well
is
sorry
about
that
I
close
that
out,
but
have
it
in
the
config
file
of
the
secret
and
so
twistlock
console
or
whatever
it
is
right.
Have
that
secret
there
then
this
output
there
is
the
mo
file
right
for
that
and
then
essentially
now
I
have
a
daemon
said
yeah
mol
and
then
you
kind
of
see
here
is
an
example.
B
This
is
on
my
kubernetes
box
as
I
go
through
just
to
show
a
couple
different
places,
because
I
didn't
get
that
far
in
the
implementation,
but
it
show
you
as
we
go
through
this
VM
will
file.
The
construct
is
the
same.
This
is
based
off
of
kubernetes,
but
as
you're
going
through.
Really
the
big
thing
that
you
account
for
and
want
to
make
sure
is
set.
Is
this
WSS
address
right?
B
So
that's
essentially
that
path
that
I
was
talking
about
for
the
defender
be
able
to
communicate
back
with
the
console
as
you
deploy
it
downstream
on
your
nodes,
the
diff
and
then,
of
course,
the
defender
is
going
to
communicate
bidirectionally
over
a
TLS
communication
over
port
80
84.
So
this
is
essentially
setting
that
daemon
set
and
then
now
you
build
the
daemon
set
out
now
you
let
the
openshift
cluster
manage
the
availability
of
your
ease
of
your
defenders
across
your
node.
B
B
What
we're
talking
about
is
that
we
really
give
you
three
artifacts,
an
artifact
for
the
persistent
volume,
my
mo
file
for
the
PV
and
then
a
Y
M
will
file
for
the
console
and
again
will
file
for
the
daemon
set
that
allows
you
to
integrate
twistlock
in
to
your
cluster
and
have
it
as
a
cluster
managed
entity
as
you're
going
through
makes
sense.
Any
questions
for
the
group
I'll
take
that
and
I'll
pause
there
I
know
we're
about
halfway
through
and
just
if
there's
any
questions,
please
come
off,
mute
and
hit
me
up
correctly.
Yes,.
A
B
No
great
great
segue,
and
so
as
you
look
through
as
you're
going
through
from
from
our
particular
perspective
right
on
our
twistlock
console,
we
have
to
learn
more
about
this
feature
so
depending
on
where
you're
at
in
the
UI.
We
have
this
page,
you
click
here
and
it's
gonna,
auto
log
you
on
and
take
you
right
to
the
corresponding
document
right.
So
there's
there.
It
is
basically
any
questions
you
have
about
setting
up
the
daemon
set
deployment.
B
You
would
walk
through
that
dot
that
document
there
as
you're
kind
of
going
through,
and
so,
if
you
had
questions
about
the
console
like
you're
going
to
hear
in
a
search,
this
is
all
search,
enabled
field
and
you
can
see
all
the
different
ways
we
have
going
through
and
installing
the
console,
as
this
going
through
to
be
completely
fair.
One
thing
that
we
are
working
on
Diane
and
for
everybody
in
the
community
to
be
aware
is
that
obviously,
you
see
all
of
our
documentation
today
is
very
specific
to
kubernetes.
B
Well,
obviously,
that
is
a
precursor
to
open
ship,
because
it's
sitting
on
top
of
that.
So
one
thing
that
we
are
doing
is
that
essentially
we
right
now
we
have
inside
of
the
documentation
we
do
have.
We
do
have
representation
for
OSI
create
as
an
example
as
we're
going
through.
So
if
you're
on
kubernetes
run
a
coop
create,
but
if
you're
on
openshift
run
an
OSI
creatives
we're
going
through,
but
we're
gonna
be
even
more
descriptive
than
that.
B
No
good.
So,
thank
you
for
done
that
first
I
apologize
I
went
right
into
how
it
was
running
instead
of
how
you
should
deploy
it.
So
that
was
on
me
as
you
kind
of
going
through.
But,
like
said
what
I?
Hopefully
you
take
away
from
this-
is
that
we
make
it
really
really
easy
to
generate
the
mo
files
and
execute
the
mo
files
to
deploy
the
product.
So
most
customers
not
having
any
pre
cursory
knowledge
of
the
product
can
deploy
this
really
really
seamlessly
by
integration,
with
your
DevOps
teams.
B
Those
kind
of
things
like
that,
as
you're,
going
through
all
right
and
so
now
kind
of
carrying
on.
If
there's
no
other
questions
about
deployment
set
up,
architectures
you're,
going
through
now
kind
of
spend
the
next
half
an
hour
kind
of
getting
a
little
bit
deeper
into
what
we
bring
now
that
you've
got
twistlock
deployed
across
your
OpenShift
cluster.
B
What
we
provide
from
a
topology
perspective
from
a
view
perspective
and
from
a
restriction
perspective
as
we're
going
through
all
right,
and
so,
as
we
look
at
this
a
little
bit
deeper,
going
back
to
where
I
was
at
before.
Really,
what
we're
talking
about
when
we
do
the
static
analysis
is
really
breaking
down
the
different
layers
that
exist
in
the
image
for
the
purposes
of
generating
a
bill
of
materials.
And
so
here
we
have
the
bill
materials
for
the
particular
image
that
exists,
which
becomes
the
artifact
based
off
of
the
SHA.
B
As
that
image
moves
through
the
lifecycle
right
and
what's
really
unique
about
us
as
well,
is
that
you
know
hey.
We
know
developers
are
building
jar
files,
tar
files,
war
file,
zip
files,
NPM
files
and
injecting
them
in
images.
We
have
the
ability
to
crack
those
open
looking
for
binary
executables
within
we
see
that
will
actually
link
them
here
as
we're
going
through
notice.
B
We
have
some
licensing
components,
not
enforcement,
but
alerting
as
we're
going
through
that
stuff's
defined
all
for
the
purposes
of
knowing
what
to
link
vulnerability
data
to,
and
this
is
what
gets
into
a
lifecycle
portion
of
the
conversation.
Now
that
we
have
that
Bill
of
Materials,
whether
we
develop
that
Bill
of
Materials
in
the
CI
in
CDR
out
and
running
someone
skipped
the
entire
CI
process.
Does
a
docker
pull
on
a
node
right
right
from
docker
IO
as
an
example,
we
can
generate
that
bill
of
materials
and
do
all
the
corresponding
alerting
notification.
B
All
that
kind
of
stuff
like
that
that
exists,
but
the
base
as
we
go
through
is
now
that
we
have
that
Bill
of
Materials.
Now
we
can
start
basically
linking
and
vulnerability
data
as
we're
going
through,
and
so,
as
you
look
at
it,
the
really
cool
part
about
it
is
that
we
have
a
SAS
service
and
really
when
you
look
at
the
SAS
service,
it's
a
real-time,
intelligent,
CVE
streaming
service
which
does
normalization
of
content
over
30
different
providers
right.
B
So
as
you
look
at
it
from
your
perspective,
you
know
you're
running
rail
or
atomic,
and
your
deployment,
role-based
images
in
your
environment
and
all
that's
propagated
through
so
at
all
those
feeds
are
gonna,
be
pulled
in
and
then
we
actually
are
purpose-built
to
go
through
because
when
I
say
over
30
different
providers,
you
know
one
thing
that
we
do
that's
unique
is
we
we
pull
from
NIST
the
NVD
database.
We
also
pull
from
the
rel
oval
feet.
We
pull
from
all
the
different
distro
oval
feeds.
B
We
pull
all
the
different
language
oval
feeds
we
pay
for
a
certain
vulnerability
data.
We
have
partnerships
with
Proofpoint
to
give
us
a
IP
and
malware
content.
We
have
a
partnership
with
a
zero-day
mal
hunter
company
called
Exodus,
which
gives
us
our
zero
date
content
as
we're
going
through,
and
so
now
what
we
do
is
we
pump
machine
learning
into
here,
and
so
essentially,
what
we're
talking
about
is
making
intelligent
decisions
about
which
source
from
which
vendor
we
want
to
port
in,
for
this
particular
package
in
this
particular
image.
B
B
That's
why
I
want
to
be
very
descriptive
when
I
say
whether
it's
real
time
or
near
real
time
as
we're
going
through,
but
now
that
you
have
that
data
as
we're
going
through
like
I
said
all
this
information
will
be
pumped
in
we're
going
through
and
sourcing
in
the
most
accurate
information
that
we
can
based
off
of
off
of
that
feed
data.
That's
coming
in,
so
we're
not
pulling
from
one
or
two
sources
and
doing
a
raw
dump,
we're
actually
intelligent.
B
Looking
through
that
feed
data
and
figuring
out,
which
is
the
most
accurate
source
to
pull
in,
you
can
see
here,
I'm
running
a
syn
OS
based
image.
There's
the
SHA
all
stuff,
like
that.
You
know
when
I
pull
off
this
particular
package.
That
particular
package
is
right
off
of
Mist
NBD
right
as
I'm
kind
of
going
through,
but
as
I
go
downstream
and
other
packages.
That
conversation
is
different
right.
You
can
see
here.
B
Depending
on
which
packaging
we're
gonna
be
sourcing
in
you
can
kind
of
see,
we
went
over
to
snick
for
this
particular
information
to
pull
in
particularly
from
age
information
about
this
particular
package
as
we're
going
through
so
very,
very
sourced,
very
purpose
bill
really
focused
on
remediating,
the
false
positives,
all
those
kind
of
things
like
that
as
we're
going
through,
and
so
as
you
look
at
it
really.
The
idea
and
the
premise
and
and
and
the
really
the
purpose
here
is
to
build
the
baseline,
good,
bad
or
indifferent.
B
You
have
the
base
on
of
your
environment
right
and
that's
essentially
what
this
dashboard
is
giving
you
is
that
baseline
as
we're
going
through,
but
we
don't
stop
there
as
you're
going
through.
We
give
the
baseline
of
your
hosts
layer
as
well
so
you're
running
those
rel
based
hosts,
we're
gonna,
give
you
the
vulnerability
and
the
compliance
state
of
those
essentially
the
same
way.
B
We
do
with
the
images
we're
gonna
basically
build
out
that
donor
materials,
and
now
we
know
what
vulnerability
and
compliance
data
to
link
in
there
as
you're
going
through
and
then
so
what
we,
what
we
do
next
from
a
perspective,
is
we
have
another
layer
of
analytics
right?
It's,
oh,
hey!
Thanks
twistlock,
you
told
me
have
a
thousand
vulnerabilities
right.
What
do
I
even
do
with
that
data
right
as
an
example?
B
So,
as
you
look
at
like
our
explorers,
really,
the
explorers
are
really
likes
at
pumping
and
analytics
to
give
you
some
some
really
direction
for
remediation.
And
so,
as
you
look
here,
you
know
here's
the
particular
CVE,
maybe
it's
a
low
or
a
medium
or
a
critical
CVE,
but
what's
more
important
is
where
is
that
CV
actually
propagated?
And
so
here's
the
configuration
data
for
the
propagation
of
that
CVE
here
I
can
see.
Here's
the
image,
here's
the
container,
here's
the
host
image
container
host.
B
This
is
just
an
image
not
actually
deployed
in
a
container
anywhere,
but
as
I
look
across
these
containers
are
all
in
different
states.
This
one
is
actually
exposed
on
the
Internet
running
as
route
running
a
high
sexy
VE.
This
actually
represents
the
most
risk
to
my
organization.
That's
why
it's
ranked
number
one.
This
one
I
probably
want
to
remediate
first
as
I'm
going
through,
and
then
we
give
you
all
of
that
data
as
we
go,
so
they
can
propagate
that
out.
B
You
know
all
that
stuff's
gonna
be
deployed
as
I'm
kind
of
going
across
this
particular
container
has
a
couple
of
different
infractions
on
it.
So
if
I
remediated
them,
this
is
the
one
that
represents
the
most
risk,
and
this
is
a
bubbling
up.
Type
of
topology
right
ira
mediate.
One
two
becomes
one:
eleven
becomes
ten
as
we're
going
through
until
you've
remediated
all
those
those
risks
that
exist
out
there.
B
We
also
affect
the
CI
CD
pipeline
process,
so,
as
I
talked
about
in
Jenkins,
we
have
the
ability
not
only
to
warn
but
to
affect
and
block
images
that
that
violate
that
the
vulnerability
threshold
or
the
governance
threshold.
That's
on
the
CI
portion
of
the
conversation
when
you
get
into
the
CD
portion
of
the
conversation.
We
provide
blocking
mechanisms
here
as
well
as
you
look
through,
so
maybe
on
your
on
your
infrastructure
nodes
or
your
app
tier
of
your
of
your
open
shift
cluster.
B
What
was
built
right
so
maybe
a
developer,
builds
a
clean
image
and
that
image
gets
posted
to
your
openshift
registry.
But
now
that
image
has
been
sitting
in
the
registry
for
a
day
or
a
week
or
two
weeks,
and
now
it's
got
vulnerabilities
on
there
right.
Maybe
you
missed
the
alerting
notification
and
someone
just
and
openshift
picks
it
up
and
tries
to
do
a
deployment
off
of
that
right.
So
now
you
just
be
basically
have
you
know,
carte
blanc
through
orchestration,
deploying
basically
a
vulnerable
image
as
a
pot
in
your
container.
B
What
we're
basically
saying
here
is
I
can
actually
block
that
topology
as
I'm
kind
of
going
through.
You
can
set
the
threshold
as
I'm
kind
of
going
about.
I
have
a
lot
of
granularity
for
what
type
of
thresholds
I
wanted
to
fine
across
what
entities,
and
then
I
could
get
very
prescriptive
for
where
I
deploy
that
what's
very
common,
when
you
look
at
OpenShift
apologies
is
multiple.
Customers
have
multiple
swimlanes
for
their
OpenShift
clusters.
B
Maybe
you
know
one
one,
two
three
or
maybe
five
downstream
pre
prod
based
clusters
and
then
maybe
a
single
or
multiple
pre-production
clusters,
because
maybe
one
clusters
PCI
and
other
clusters,
HIPPA
or
whatever
that
that
setup
might
be.
We
have
the
ability
to
segment
policy
across
those
resources
as
we're
going
through,
so
I
can
go
through
here
and
basically
add
in
all
my
nodes
may
be.
This
is
a
five
node
cluster
right,
I
could
add
them
in
individually
node
one,
no
two,
whatever
it
might
be,
is
I'm
kind
of
going
through.
B
But
that's
really
where
the
labels
come
in,
because
everything
in
pre
prod
is
gonna,
be
you
know,
customer
dot
tree
dot.
You
know
whatever
it
is,
and
I'm
gonna
do
a
star
and
now
I've,
just
sucked
in
the
entire
cluster
into
that
particular
policy
and
I'm
basically
defined
a
posture
for
that
cluster
Ryan
says
I'm,
going
through
and
what's
very,
very
common.
Is
customers
use
the
policy
setup
to
basically
tear
out
their
environment
so
as
I'm
going
through
so
I
can
define
hey,
look
from
a
vulnerability
perspective
upstream
or
downstream.
B
B
I
want
to
block
vulnerabilities,
so
I'm
actually
being
run
there
in
production
as
I'm
kind
of
going
through,
and
that's
a
normal
type
of
setup
that
customers
actually
have
deployed
with
our
product
as
are
going
through
all
right,
make
sure
there's
not
any
other
questions
as
I'm
kind
of
going
through,
but
that
gets
into
the
other
part
of
the
product.
Not
to
the
perspective.
We
do
a
native
dump
into
sis
logs,
so
from
an
open
shift
perspective.
You
know
open
ships
writing
into
the
syslog
feed.
We
do
a
st..
B
We
do
a
write
in
facility,
one
of
syslog
as
well.
So
if
you're
already
doing
dumps
from
a
syslog
perspective
into
a
sim
off
of
your
open
shift
setup,
we
can't
I
natively
into
that
and
then
give
you
the
audit
data
off
of
the
open
shift
nodes
as
well
as
the
pods
and
containers
and
images
up
above
as
well
as
you're
going
through.
B
Maybe
you
have
a
slack
channel
or
JIRA
for
a
ticketing
perspective,
or
you
have
SMTP
move
the
ability
to
integrate
there
and
then
segment,
not
only
what
Avenue
the
the
data
is
going
pumped
out,
but
who
do
you
want
to
send
that
data
to
what
type
of
data
do
you
want
to
send
them
and
at
what
frequency
do
you
want
to
send
that
data
with
me?
So
far?
That's.
B
And
that
was
where
I
was
wanted
to
get
to
this
point.
Kind
of
dump
through
is
give
you
a
base
example
of
vulnerabilities
and
then
how?
How
do
you
operationalize
this
right
and
that's
really
the
key
term
as
you
look
through
it
is.
What
do
you
do
with
this
data
right?
It's
one
thing
for
us
to
give
you
all
the
data,
but
how
do
you
actually
use
it?
What
do
you
actually
do
with
it
right
and
that's
that's
the
premise
of
how
I
wanted
to
really
tailor
this.
B
So
as
you
look
at
it,
this
product
is
not
designed,
nor
is
it
needed
for
you
to
live
in
here
all
day
every
day
as
you're
kind
of
going
through.
So
that's
what
the
alerting
we're
a
REST
API
based
product.
We
have
all
the
alerting
notification
through
the
defenders
and
through
the
the
configuration
data
through
the
the
policy.
B
We're
gonna
build
a
lot
of
information
about
your
particular
environment,
and
now
you
kind
of
build
through
twistlock
say
how
do
I
want
to
distribute
that
information
right
as
a
developer,
built
an
image
and
that
image
has
vulnerabilities
I
want
to
be
notified
of
that.
If
somebody
posts
an
image
that
has
vulnerabilities
I
want
to
be
notified
about
that
I
have
a
production
image
that
is
clean
or
approaching
pod.
That
is
clean,
but
now
a
zero-day
just
hit
it.
I
want
to
be
notified
right.
B
All
that
stuff
like
that
is
really
how
we're
built
out
as
you're
going
through,
and
so
you
set
your
email
chain
and
now
a
zero-day
hits
boom
boom
x,
y&z
people
get
notified
or
a
developer
post,
an
image
that
has
these
vulnerabilities
boom
x
y&z
people
get
notified
as
you're
going
through.
You
don't
have
to
live
in
the
console
and
then
waiting
for
an
alert
all
that
kind
of
stuff
like
that
off
of
the
alert
we
build.
The
notification,
cascaded
downstream,
makes
sense.
A
B
Right,
we
do
the
same
things
on
the
governance
side
right
just
like
I
talked
about
as
well.
What's
really
cool
here
as
you
go
through,
we
as
a
company
twistlock
as
a
company,
have
really
made
a
couple
of
key
contributions
to
the
ecosystem.
One
around
C
is
not
only
C
is
for
docker,
but
C
is
for
kubernetes
right,
so
those
are
native
to
the
product,
here's
all
the
docker
configs
and
here's
all
the
kubernetes
config.
So
as
you
deploy
your
your
openshift
cluster,
we're
gonna
help.
B
You
maintain
the
baseline
of
the
ACT
apology
right
as
you're
kind
of
going
through
right
all
from
a
security
point
of
view,
as
you're
kind
of
going
through.
So
you
can
see
here
about
300.
Almost
400
plus
checks
are
here
out
of
the
box
as
you're
kind
of
going
through,
and
we
also
have
the
ability
to
extend
right
so
whether
it's
through
open,
scat,
Red
Hat,
has
an
open,
scab
capability.
B
You
kind
of
see
here,
here's
an
open,
scat
XML
that
we
kind
of
built
out
and
a
lot
of
customers
are
using
this
to
get
very
application.
Centric
think
I
want
to
build.
This
is
really
saying:
hey,
look,
I,
don't
want
to
deploy
privileged
containers.
I,
don't
want
running
his
route.
I,
don't
want
the
ability
to
SSH
those
kind
of
things
like
that,
but
more
graeme,
they
would
say.
B
B
If
a
host
has
these
settings
right
as
the
Masters
deployed
as
an
RPM
or
as
a
container
obviously
which
settings
would
apply,
would
be
important,
but
we've
got
it
covered
from
both
perspectives
as
we're
going
through
and
saying
here
and
now
we
can
go
through
and
say,
hey
look!
This
is
what
my
master
has
to
look
like
when
I
deploy
it.
This
is
what
my
API
server
my
worker
nodes.
B
What
they
look
like
what
communication
structure
they
have
all
that
kind
of
stuff
like
that
is
defined
if
I'm
doing
Federation,
which
is
upstream
from
that
to
the
perspective.
Not
a
lot
of
customers
do
in
Federation
yet,
but
we're
starting
to
see
an
uptick
of
Federation
I'm,
pretty
sure
that
OpenShift
supports
Federation
Dian.
B
You
have
to
keep
me
honest
on
that
one
from
from
Ashley
perspective,
but
that's
all
defined
there
as
you're
kind
of
going
through
all
right
so
pivoting
off
of
that
as
you
look
at
vulnerabilities
and
compliance
really
just
think
that
these
really
those
two
constructs
are
really
there
to
define
your
CI
CD
portion
of
the
product
right
so
really
handling
your
static
base
content.
So
now,
as
we
move
upstream,
that's
where
access
control
comes
in
runtime
and
firewalls.
I
won't
talk
about
access
control
today,
because
selfish
selfish,
a
plug
there.
B
We
actually
wrote
the
the
basically
an
Aussie
plug
into
the
docker
daemon
itself
on
the
open
source
side.
It's
actually
what
openshift
leverages
to
provide
the
access
control
mechanisms
there.
So
essentially
it's
basically
it's
a
feature
parity
there
as
you
look
between
what
how
we
do
access
control
and
how
openshift
does
access
control,
because
they're
using
the
same
engine
underneath
so
to
speak
from
from
a
plug-in
perspective,
but
really
starting
out
as
we
kind
of
go
through
now,
we've
gone
through
and
we've
secured
our
CI
CD
pipeline
process.
B
We've
got
refined
how
images
actually
get
built,
how
images
get
deployed
now.
The
only
thing
we're
really
concerned
with
is
drift
off
of
that
set
up
as
we're
kind
of
going
through,
which
is
really
as
a
base
is
how
runtime
is
built
out.
How
we
do
this
is
is
automatically
through
modeling
right
as
an
example
as
we're
going
through,
and
so
what
we
really
have.
B
As
you
look
at
it,
the
defender,
which
is
sitting
on
all
your
open
shift
nodes,
is
leveraging
RZ
as
plumbing
down
into
the
kernel
right
and
essentially,
we
have
some
sensors
that
we
drop
down
in
the
from
a
perspective,
so
we
can
as
essentially
record
and
listen
to
transaction,
that
traverse
those
sensors
right,
and
so,
when
you
get
into
orchestration
and
restriction
of
orchestration
and
someone
bypasses
think
someone
elevates
out
of
the
orchestration
engine
tries
to
do
something
through
that.
Conduit
is
really
how
we
restrict
alert,
notify
all
those
particular
things
like
that.
B
B
Think
of
us
as
going
into
record
mode
all
these
sensors
a
process
sensor,
a
network
sensor,
a
filesystem
sensor,
a
system
call
sensor
goes
into
record
mode
and
we're
looking
at
to
base
things
static
is
first
and
foremost.
Obviously
we
got
that
from
the
docker
file,
but
behavioral
is
all
that
metadata
now
that
the
container
is
up
and
running
what
is
it
actually
doing,
and
so
at
a
base
level?
Here's
what
processes
you're
allowed
to
vote
invoke
here's!
B
What
network
calls
you're
allowed
to
make
here's
what
file
system
transactions
and
system
call
transactions
you're
allowed
to
make?
We
do
the
same
thing
on
the
hosts
layer
right.
We
provide
that
runtime
protection
on
the
host
layer
right,
there's
the
child
processes
all
that
stuff,
like
that,
as
I
go
through
notice,
the
behavioral
content
that's
defined
there
once
we
have
that
that
met
it
once
we
have
that
model,
essentially
everything
that
happens
off
the
back
end
of
that
we
generate
an
audit,
because
the
premise
of
the
models
is
to
generate
to
grab
the
operational
intent.
B
So
obviously
malicious
is
part
of
that
right.
But
it's
not
the
only
thing
we
look
at
this
containers.
Purpose
in
life
is
to
run
Jenkins
if
it's
all
of
a
sudden
run
cat
entities
or
entities
or
something
like
that
that
is
outside
of
the
intent
we
are
going
to,
let
you
know,
but
these
can
get
rather
noisy
as
you're
kind
of
going
through
right
for
Fraxel
perspective,
and
so
that's
essentially,
what
incident
explorer
is
another
set
of
analytics
from
that
to
the
respective
we
have
a
set
of.
B
We
have
a
set
of
algorithms
that
comb
through
those
audit
trails,
looking
for
trends
and
anomalies
right
of
a
malicious
intent
and
pulling
them
out
as
incidents
right.
So
you
can
see
an
example
kill
chain
here.
Here's
the
entire
forensic
trail
of
what
actually
transpired
see.
So
someone
came
in
made
a
system
call
which
did
a
file
system
right,
it's,
etc,
etc,
etc.
You
can
see
there's
16
steps
in
this
kill
chain,
but
as
I
go
down,
you
know,
here's
a
more
complex
one.
This
is
92
step
kill
chain
as
we're
going
through.
B
All
this
is
defined
through
file
system.
Writes
network
calls
all
that
stuff
like
that
is
gonna,
be
defined
here
as
we're
going
through.
The
key
thing
to
really
think
about
here
is
essentially
any
one
of
these
actions
by
themselves:
don't
necessarily
dictate
a
kill
chain
or
a
trend.
It's
the
commits.
The
collective
of
them
together
is
what
actually
builds
that
out.
Then
we'll
actually
look
north
and
south
of
that
event.
Look
for
other
things
in
that
field
and
that's
how
we
build.
You
know:
kill
change,
botnet
attack,
Strozier
horse
attacks,
X
equal
injection
attacks.
B
Do
you
want
to
block
it,
or
do
you
want
to
prevent
it
right,
so
obviously
block
means
to
kill
the
container,
kill
the
pod
and
obviously
from
an
open
shift
perspective
when
we
kill
a
pod
open
ships,
gonna
try
to
spin
that
back
up
in
blocking
we
actually
kill
and
put
into
a
forensic
state
to
prevent
that
that
redeployed
from
an
open
shift
perspective,
but
so
that's,
obviously,
really
really
intrusive.
What's
more
tactful
and
more
useful
is
really
the
prevent
button,
we
know
what
processes
you're
supposed
to
invoke
if
something
gets
invoked
on
the
container.
B
That's
not
on
this
list.
We
want
to
block
that
process.
We
want
to
block
that
filesystem
right,
I'm,
gonna
block
that
Network
packet
as
we're
going
through
and
I
know.
We
have
about
six
minutes
left
so
I'll
close
it
out
with
the
firewalls
and
then
open
it
up
for
Q&A
in
the
last
couple
of
minutes.
So
the
key
thing
I
want
to
leave
you
with
is
that
on
the
runtime
side,
we
really
give
you
in-depth
data
about,
what's
actually
transpired
outside
of
it
from
a
modeling
perspective.
B
What
changed
on
your
model
and
then
give
you
meaningful
ways
about
how
you
react
to
that
right.
Do
I
want
to
do,
alerting
a
notification
or
do
I
want
to
actually
block
it
right.
So,
as
you
look
here,
you
know
here's
our
laughs
as
an
example
we're
building
out
more
additional
capabilities
as
we're
going
through
I
have
a
real,
simple
rule
here
to
say:
hey
look,
I
want
to
block
the
ability
for
anybody
to
do
it
to
basically
talk
to
this
web
page
via
a
browser
Ryan.
B
So
an
all-or-nothing
kind
of
scenarios
I'm
going
through
so
I-
can
set
this
to
blocks
real,
quick,
real,
quick.
If
I
go
here
and
now
we
just
kicked
in
real
dynamically
and
blocked
a
particular
container
from
going
through
all
the
while
as
I
go
through.
You
can
see
here
a
docker
PS
if
I
could
type
right.
B
B
It's
been
up
for
six
days
right,
so
I
can
simply
go
over
here,
set
this
back
and
actually
set
that
to
alert,
go
through
and
then
refresh,
and
then
that
now
I
let
the
package
diverse
to
come
through
right,
so
we
never
actually
killed
the
container.
We
just
block
those
packets.
So,
as
you
look
here,
we
have
the
ability
to
do
that
from
a
layer,
seven
perspective
as
well
as
a
layer.
Three
perspective.
What's
really
cool
here?
Is
we
look
through
on
the
layer
three
perspective?
B
We
know
through
modeling
from
a
static
and
a
behavioral
perspective.
What
the
network
transactions
are
right,
whether
it's
a
docker
compose
you
have
certain
pods,
it's
supposed
to
communicate
with
each
other.
We
know
all
that
through
the
modeling
right
now.
Do
you
want
to
prevent
any
drift
off
of
that,
or
do
you
those
kind
of
things
like
that
so
now,
from
a
layer
three
perspective,
now
all
of
a
sudden,
80
84
is
only
allowed
inbound,
but
if
all
of
a
sudden
it
makes
an
port
80
call
back.
What
do
we
want
to
do
with
that?
B
A
A
A
Have
a
way
to
segment
it
out
and
send
it
off
the
Procrit
people
are
into
the
appropriate
channel
it
just
it's
it's
great,
its
visual,
it's
wonderful!
But
it's
in
order
to
make
operationalize
that
you
really
need
that
and
a
learning
capability
built
and
as
well.
So
it's
much
appreciated
on
folks
like
myself
and
as
always
when
you
come
out
with
a
new
release
or
if
you
have
a
customer
or
someone
who's
using
it
in
an
interesting
way
or
has
a
great
case
study.