►
From YouTube: DevSecOps is the Way (S1E8): Monitoring Month! OpenShift Threat Detection and Forensics
Description
In this monthly series, learn how Red Hat weaves together DevOps and Security to master the force called DevSecOps. This show brings you Red Hat products and our security ecosystem partners to aid in your journey. October is Logging and Monitoring month! In this episode, we will discuss how containers and cloud introduce new challenges that complicate security and compliance. How do you capture the activity within your Red Hat OpenShift clusters and cloud infrastructure to monitor and report on what’s happening?
Join Alex Lawrence, Principal Solutions Engineer at Sysdig, as we discuss how DevSecOps teams can effectively capture the data needed to detect threats, satisfy audits, and perform forensics across OpenShift clusters in private, public, and hybrid clouds. Hear how open source tools like Falco, as well as commercial offers from Sysdig can help you reduce risk. Bring your lightsaber and be prepared to train hard... may the DevSecOps be with you!
A
All
right-
yes,
indeed,
that
dramatic
music
means
only
one
thing
and
it's
time
to
talk
security
in
another
episode
of
devsecops
is
the
way
welcome
to
all
my
internet
friends
across
the
globe
and
watching
this
either
through
twitch
or
youtube.
This
is
episode.
8
of
devsecops
is
the
way
my
name
is
dave.
Muir,
I'm
a
global
principal
solutions,
architect
here
at
red
hat,
I'm
focused
on
our
security
isvs,
typically
those
folks
who
work
with
us
on
top
of
openshift
and
ansible,
and
we
have
a
fantastic
show
for
you
today.
A
You
can
see
that
we've
been
doing
this
since
march,
and
we've
had
different
categories
every
month,
we're
actually
in
the
planning
stages
of
what
we
should
do
next
year
in
terms
of
each
month,
but
for
the
series
for
the
monthly
series
we
put
out,
podcasts
red
hat,
live
streaming
shows
like
this
one
blogs
for
any
information.
You
can
always
look
at
red.ht
forward,
slash
devsecops
alrighty,
so
with
that
I
am
going
to
bring
in
alex.
B
A
A
A
B
A
A
A
A
B
B
When
I
was
at
pacific
lutheran
university
around
a
few
different
projects,
predominantly
shibboleth
and
cavs
so
trying
to
deal
with
identity
who
you
are
authority
and
access
management,
I'm
kind
of
that
whole
stack
of
things
and
plu
ended
up
building
a
really
intriguing
system
based
on
those
by
integrating
their
erp
banner
as
kind
of
the
source
of
identity
into
their
various
directories.
Right
they
ran
multiple
different
ones.
They
had
to
use
a
special
schema,
called
edu
person
that
most
universities
use,
and
so
then
it
was
a
matter
of
figuring
out.
B
You
know
what
can
be
used
against
things
like
that,
and
so
it
was
a
really
novel
way
to
implement
kind
of
that
whole
open
source
stack
on
identity.
I
think
these
days,
they've
been
gotten
to
the
point
where
they've
integrated,
two-factor
authentication,
with
duo
and
things
like
that
into
the
solution
set
it's
being
ran
by
by
david
allen
and
darren
strothers
over
at
at
plu.
These
days
really
really
cool
solution.
B
A
B
Yeah
yeah,
that
was
one
of
the
design
goals
with
the
project,
was
to
capture
metadata
about
who
the
individual
was
when
they
were
generating
passwords
so
that,
as
you,
create
a
password
and
you
created
them
with
better
entropy
you'd
be
able
to
kind
of
get
a
quick
view
of
what
other
people
had
been
doing.
So
the
example
I
always
used
was,
if
you're
a
if
you're
a
computer
science
professor
and
you
have
to
make
your
new
password
it.
Wouldn't
it
be
great
if
we
can
start
displaying.
B
You
know
the
entropy
level
on
average
that
your
students
have
that
you're
teaching
or
the
entropy
level
of
other
faculty
in
the
university
like
in
the
humanities
department
or
the
library
employees
right,
like
you
know,
how
did
you
compare
to
other
groups
on
campus
and
you
know?
Maybe
you
should
feel
bad
that
your
entropy
is.
You
know
a
factor
of
10
worse
than
these
other
people,
these
other
groups,
and
maybe
you
should
do
better
right.
We
weren't
telling
people
that
they
had
to
have
these
ridiculously
complex
passwords.
B
We
were
just
encouraging
them
to
have
better
entropy,
based
off
of
kind
of
who
they
were
and
what
they
were
and
the
whole
goal
there
was.
You
know
we
shouldn't
dictate
to
people
that
they
have
to
have
so
many
characters,
and
so
many
exclamation
points
or
special
characters,
caps
numbers
all
that
jazz.
If
your
entry
enterprise
high
and
it's
it's
good,
you
know
why
can't
that
qualify,
and
so
you
know
I
was
notorious
for
using
movie
quotes
as
passwords,
because
they
were
easy
to
remember.
B
I
could
type
them
out
well
right
had
spaces
and
other
things
in
them.
It
made
them
complex
and
it
was
a
an
easy
way
to
do
passwords
for
me
personally,
and
that
was
kind
of
the
whole
goal
was:
let's
enable
our
users
to
to
do
this
well
without
being
bogged
down
by.
You
know,
random
character
generation
and
things
like
that
right.
A
B
Yeah
yeah,
so
so
systig's
kind
of
whole
stance
on
this
world
is
in
the
in
the
cloud
native
world
in
this
devsecops
world.
A
lot
of
the
projects
we're
all
using
in
production
to
build
our
applications
are
derived
from
open
source.
You
know
whether
or
not
they
are
an
implementation
of
an
open
of
an
open
source
project
or
they
are
open
source
themselves.
They
they
are.
B
B
So,
if
you're
trying
to
have
a
closed
source
solution,
do
everything
security
for
kubernetes
that
that's
a
difficult
model,
because
you're
basically
saying
that
you
know
my
my
300,
my
500
developers
are
better
and
faster
at
producing
applications
and
producing
code
than
the
entire
rest
of
the
globe.
Supporting
this
one
particular
project
right,
and
so
because
of
that
belief,
a
lot
of
what
we
do
here
at
sysdig
is
derived
in
the
open
source
space.
So,
like
our
our
runtime
engine
is
falco,
it's
a
cncf
project
that
we
donated
to
them.
B
A
Right
yeah
so
well
said
I
heard
I
was
at
kubecon
actually
last
week
and
you
just
just
get
that
same
feeling
that
the
community
is
so
vibrant
and
rich
and
and
there's
a
lot
of
people
from
different
companies
just
contributing
to
to
making
these
projects
better
right.
So
yeah
and
trying
to
do
that
within
closed
source
with
a
small
team
is
doesn't
even
obviously
scale
or
compete
with
something
like
you
know,
a
global
community,
exactly
cool!
A
B
Yeah
yeah,
so
I
think
the
best
place
to
start
is
to
kind
of
just
level
set
a
little
bit
about
the
way.
Systig
works,
kind
of
the
way,
our
our
core
of
the
product
functions
and
gathers
data,
and
from
there
I'm
just
going
to
jump
right
into
demos
and
showing
stuff
off
right.
We
don't
want
to
want
to
bore
people
with
slidewear
or
kind
of
walk
through
value
prop,
let's
just
get
into
the
nuts
and
bolts
of
the
nerdy
things
and
have
a
little
bit
of
fun.
B
Cool,
so
this
here
is,
admittedly,
a
picture
of
a
slide,
so
I
do
apologize
for
that,
but
it
illustrates
the
way
systig
approaches
instrumentation
in
the
world,
and
so
we
have
a
couple
different
things.
We
already
talked
about
falco
and
we
talked
a
little
about
systig,
there's,
also
an
open
source
variant
of
of
cystig,
that
is
the
same
name,
says,
dig
and
the
end
of
the
end
of
the
day.
B
They
do
a
very
similar
instrumentation
model
and
what
that
is
is
to
inject
a
kernel
module
or
an
ebpf
application
into
the
host
kernel
right.
When
you
start
talking
containers
in
kubernetes
and
a
distributed
world,
you
don't
have
things
like
a
switch
or
a
span
port
or
the
ability
to
capture.
You
know
packets
across
the
infrastructure
in
a
way
like
wireshark
used
to,
and
so
how
do
you?
B
How
do
you
build
tools
that
have
ultimate
observability
and
from
both
a
monitoring
perspective
and
a
security
perspective
when
you
can't
grab
packets,
you
can't
instrument
the
infrastructure.
The
switching
to
things
like
that
and
systick's
approach
is
okay.
Well,
let's
go
to
the
least
common
denominator:
let's
go
to
the
host
kernel
right.
So
if
we
instrument
the
kernel,
we
can
then
see
all
of
the
things
coming
out
of
the
containers
that
are
running
above
that
kernel.
We
can
see
all
of
the
the
processes
all
of
the
applications.
B
And
so
what
that
looks
like
in
the
actual
product
itself
is
it
gives
you
you
know
metrics
and
data
across
everything,
be
that
from
individual
processes
or
containers
or
pods.
We've
done
the
same
thing
by
instrumenting,
the
kubernetes
api
and
cloudtrail,
and
things
like
that
across
the
infrastructure.
B
That
what
that
really
means
for
the
user
base
is
that
you're,
not
just
stuck
with
system
calls
anymore
against
the
falco
runtime.
You
can
now
ingest
logging
data
as
well
to
be
able
to
react
to
events
that
come
through
that
and
so
in
our
world.
That's
really
like
ingesting
the
kubernetes
audit
api
and
taking
actionable
events
from
that
and
be
able
to
do
something
with
it
or
from
the
cloud
trail,
logging
from
aws
or
one
of
the
other
major
clouds
and
being
able
to
react
to
events
happening
across
your
infrastructure.
B
So
in
the
monitoring
world,
this
is
really
about
looking
at
metrics
right
looking
at
processes
looking
at
stuff
going
on
across
your
clusters
and
right
now
this
is
kind
of
just
a
high
level
overview
of
various
ones.
In
our
lab,
I
can
highlight
a
particular
cluster
and
I
can
get
into
all
sorts
of
events
coming
from
it.
So
in
this
case
you
can
see,
we've
got
a
lot
of
back
offs
happening.
B
It's
the
demo
environment.
It's
not
unexpected
if
you
saw
something
like
this
in
your
production
environment,
this
should
be
indicative
of
a
problem
right,
and
so
maybe
you
want
to
investigate
that
further
and
so
ways
you
can
do.
That
is
to
come
in
and
look
at
things
like
are
my
nodes
up
and
running.
Do
I
have
all
the
pods?
I
would
expect.
How
do
my
resources
look
across
that
cluster?
Maybe
I
should
dive
into
the
namespaces
look
at
my
applications
running
in
the
particular
cluster.
B
Look
for
areas
where
you
might
have
issues
so
like
this
java
application.
We
can
see
that
it
is
showing
a
significant
over
commit
on
memory.
So
if
I
highlight
that
I
can
see
what's
going
on
in
here
event
wise,
we
see
a
number
of
containers
dying
off,
containers,
unhealthy
and
so
really.
This
interface
is
about
aggregating
data
up
to
a
central
place,
to
give
you
quick,
quick
overviews
and
quick
views
of
what's
going
on
inside
that
infrastructure.
B
This
is
ever
evolving
in
systig.
You'll
see
this
overview
page
changing
here
in
the
future,
with
other
information
and
more
data
as
well
to
help
people
troubleshoot
and
see
what's
going
on,
but
the
general
concept
here
is
just
highlighting
workloads,
highlighting
services
and
trying
to
give
you
deep
information
into
what's
going
on
across
that
stack
and
where
you
might
be
having
issues
like
in
this
case,
we
can
see
a
cassandra
workload
inside
that
java
application
is
having
a
service
degradation
problem
right
and
it
likely
is
because
we're
very
much
exceeding
member
utilization
right
yeah.
B
So
with
that,
like
you
know,
we
can
take
these
metrics
and
view
them
in
different
ways.
So,
if
I
wanted
to,
I
could
come
into
a
a
different
view
like
this.
This
pod
right
sizing
view
I
can
say
well,
I
know
I'm
running
into
memory
problems.
Why
is
that
you
know
what's
going
on
and
I
can
start
looking
through
utilization
across
time
if
I
want.
B
I
can
pop
this
out
to
like
two
weeks
and
I
can
start
seeing
all
sorts
of
data,
and
especially
since
we
know
this
is
a
java
application,
we're
seeing
something
that
is
pretty
darn
descriptive
right
this.
This
seesaw
of
memory,
utilization
and
dropping
back
down
is
basically
telling
us
that
the
jvm
in
question
here
keeps
on
using
up
to
its
limit.
Garbage
collection
happens
and
it
does
it
again,
and
so,
when
we
start
seeing
that
see-saw
that
memory
requester
from
the
containers
we
know
we've
got
something
wrong
right.
You
know.
B
A
B
B
I
can
come
into
something
like
that
that
same
java
application
and
I
can
go
pull
up
a
bunch
of
different
views
here
and
the
one
for
this
one
in
particular
that
I
like
is
really
about
processes,
and
so,
if
I
just
start
typing
top
processes,
we
can
pull
up
a
dashboard
about
that
and
it'll
actually
list
out
every
single
process
running
inside
of
this
given
namespace
right.
So
am
I
seeing
things
I
shouldn't
see
right,
you
know,
what's
what's
the
java
exact
that's
going
on?
Does
that
look?
Okay,
yeah!
That's
a
cassandra
call!
B
You
know
I'm
seeing
things
like
cut
or
nginx
running,
I'm
not
really
seeing
anything
that
might
point
out
to
me
that
I've
got
a
rogue
process
in
here
that
I
should
really
care
about,
and
this
is
looking
over
the
last
two
weeks
right.
Conversely,
if
I
wanted
to
know
more
about
some
of
that
stuff,
in
particular
in
the
secure
product,
there
are
some
really
cool
ways
to
do
process
interrogation.
B
B
You
can
see
here
that
it's
detecting
crypto
miners
using
a
particular
protocol,
and
so
what
it's
doing
is
inspecting
the
syscalls
that
are
being
executed
on
the
particular
container
or
node
and
we're
looking
for
a
spawned
process
and
so
basically
saying
if
this
process
opens
up-
and
we
see
that
the
command
line
contains
this
little
string
right
here
right.
So
if
we
detect
that
we
know
this,
one
in
particular
is
a
a
minor
call
and
we
should
then
alert
on
that
condition,
and
this
is
really
just
getting
down
to
the
the
way.
B
Falco
does
run
time
detection.
You
can
do
all
sorts
of
crazy
things
here
and
be
able
to
do
all
sorts
of
different
configurations
with
that
so
like.
If
I
wanted
to
go
look
for,
say,
rogue
network
tools,
I
can
start
typing
in
something
like
network,
and
I
can
look
for,
let's
see
here,
which
one
do
I
want.
I
want
suspicious
network
tool
in
container,
and
so
this
this
runtime
rule
is
really
looking
for
various
spawn
processes
and
they
are
a
of
a
particular
list
right.
B
A
Cool
yeah,
I
should
have
mentioned
if
anyone
watching
you
want
to
ask
a
question,
feel
free
to
ask
questions.
I'm
getting
all
the
chat
here.
So
I
can
ask
a
question
for
alex
or
if
you
have
a
question
from
me,
I
don't
know
why
you
would
but
feel
free
to
feel
free
to
send
a
question.
We
did
have
a
comment.
B
A
That's
awesome,
so
I
have
a
question.
You
showed
us
a
couple
items
here.
If
you
think
about
forensics
and
when
security
events
happen,
you
probably
showed
us
this
already,
but
what?
What
are
the
most
popular
steps
or
screens
or
things
that
an
operator
would
do
with
systig
to
find
out
what
happened
and
what
action
to
take.
B
Yeah,
that's
that's
a
it's
a
really
good
question
and
the
way
we
try
to
help
people
visualize.
This
is
in
this
thing
that
we
call
insights
and
what
it's
doing
is
looking
for
events
across
your
clusters.
In
this
case,
you
can
see,
we've
got
a
few
different
ones
running
out
there,
some
in
eks
aks,
aws,
gke,
all
the
different
flavors
and
we're
surfacing
up
all
of
the
details
of
stuff
happening
in
each
one
of
those
clusters.
B
What
I
like
about
this
view,
is
we
aggregate
things
together
so
that
you're
not
getting
a
bunch
of
of
logging
data,
pushing
stuff
that
you
might
care
about
out
of
your
purview
right?
So
this
is
the
summary
we
can
see
we're
looping
things
together
like
rights
below
roots
deleting
bash
history.
So
a
number
of
of
these
events
all
kind
of
put
together.
B
If
I
go
to
my
event,
view
and
start
scrolling,
you
can
see
that
those
you
know
are
fairly
prevalent
and
start
pushing
other
things
out,
and
so
maybe
we
don't
want
to
see
it
in
that
particular
way.
We
want
to
be
able
to
visualize
it
in
a
way
that
lets
us
kind
of
surf
through
things
zoom
in
on.
What's
going
on
and
kind
of
look
deeper
at
particular
things.
So
what
I
like
to
show
here
is
that
you
know
we've
got
one
occurrence
of
launching
a
suspicious
network
tool
in
a
container.
B
You
know,
maybe
what
someone's
gonna
do
is
come
in
and
you
know
start
writing
below
root
a
ton
create
a
bunch
of
noise,
and
while
that
script
is
going,
they
can
go
and
start
doing
things.
You
actually
want
to
care
about
right,
a
view
like
this
lets.
You
pick
up
on
those
things
and
then
be
able
to
investigate
them
further.
So
if
I
highlight
you
know
the
this
one
in
particular,
I
can
see
that
they
have
the
launch
suspicious
network
tool
and
container.
B
I
can
go
click
on
it
and
I
can
get
details
about
you
know
where
it
happened
or
what
went
on.
I
can
take
it
over
to
the
events
view
and
then
I
can
get
metadata
about
it.
So
what
types
of
compliance
frameworks
would
you
need
to
care
about?
If
this
thing
were
to
launch
another
way
to
put,
that
is
if
someone
were
to
launch
a
suspicious
network
tool
in
a
container,
what
compliant
specs
would
care
about
that.
B
B
Now,
if
I
wanted
to
take
it
a
step
further,
I
can
do
other
investigation
type
stuff
as
well.
So
like
let's
say
we
have
an
event
that
comes
out
where
somebody
launches
a
terminal
right.
So
if
we
just
start
typing
terminal,
we'll
auto
filter
to
any
place
that
you
know
this
terminal
rule
pops
up,
so
we
can
see
there's
a
terminal
shell
in
the
container.
B
If
I
go
ahead
and
click
that
I
can
then
filter
on
all
those
particular
events,
if
I
highlight
the
terminal
shell
and
container
event
we'll
see
what
we
saw
before,
where
we
get
that
same
listing
of
compliancies
as
well
as
kind
of
the
scope
of
where
the
event
happens.
But
under
my
respond
offering,
I
have
this
really
interesting
view
called
activity
on
it,
and
so
one
of
the
advantages
that
systig
is
capturing
system
calls
allows
us
to
start
building
a
history
of
things
that
happened
across
shells
or
other
things
in
your
environment
for
investigation
later.
B
And
what
we'll
see
is
there?
It
is
so
we'll
see
a
cubic
zec
right,
so
somebody
came
into
this
environment.
Did
a
cube
exec
against
this
particular
namespace,
this
particular
pod
and
they
evoked
bash.
So
we
see
that
bash
opened
up
inside
of
the
directory
var
www.html
they
didn't
ls,
they
curled
a
file
down
from
github
removed
a
particular
directory.
They
untard
the
file
they
grabbed
and
that
evoked
gzip,
and
then
we
had
a
bunch
of
files
extracted
to
the
file
system
and
they
ended
with
the
classic
shredding
of
the
history.
B
So
what
I
want
to
point
out
here
is
that
it
doesn't
really
matter.
It
was
a
container,
that's
no
longer
there.
It
doesn't
really
matter
they
tried
to
shred.
You
know
the
history
of
the
file
inside
the
container
itself.
We
have
a
running
record
of
all.
The
system
calls
that
were
ran
and
we
can
go
through
and
interrogate
those
and
see.
What's
up.
So,
if
I
wanted
to
go
in
here,
you
know
I
could
go
grab
the
entire
command
line
for
the
curl.
B
That
did
and
I
can
go
inspect
that
file
in
a
protected
place
or
I
could
go
look
at
the
gzip
command
and
I
can
see
that
they
ran
tar
xcvf
right
inside
of
our
www.html
was
ran
by
uid33
pid
parent
pids.
I
can
filter
by
all
the
parent
commands
and
I
can
see
all
the
other
stuff
that
they
ran
to
make
sure
I
didn't
miss
anything.
Basically,
it
gives
me
a
very
nice
forensics
trail
to
go
through
and
investigate
after
an
event
occurs
in
my
environment.
A
B
A
number
of
these
are
also
available
in
falco,
and
so,
if
I
go
into
the
rules
library
you
can
see
published
by
here-
and
so
a
lot
of
these
are
published
by
by
systig
in
our
current
rule
set.
But
a
number
of
these
also
exist
for
falco
itself,
like
terminal
shell
and
container.
That's
a
rule
that
exists
in
falco
there's.
B
A
B
A
B
Yeah
I
mean
we
can
go
into
all
sorts
of
different
stuff
right.
The
the
solution
here
really
is
about
kind
of
the
whole
life
cycle
of
of
application.
We've
talked
a
lot
about
kind
of
the
the
runtime
world,
the
runtime
security
aspect
of
things,
which
is
definitely
a
strength
of
cystic
and
falco,
but
there's
other
areas
that
are
kind
of
interesting
too.
B
Like
one
thing
I
like
to
point
out
to
a
lot
of
our
customers
is
that
we've
implemented
a
a
fairly
unique
way
of
doing
network
security
policy
inside
your
cluster,
and
it's
because
of
our
data
source
being
it
system,
the
system
call
level
effectively.
What
we
can
do
is
come
into
a
cluster,
so
we're
looking
at
an
aks
cluster.
This
is
again
our
little
friendly
java
application
and
we
can
build
topology
maps
of
the
way
traffic
is
flowing
through
your
application.
B
One
of
the
areas
customers
come
to
us.
A
lot
is
around
compliance
needs,
and
this
particular
view
here
helps
significantly
with
that.
Normally
one
of
kind
of
the
table
things
you
have
to
do
when
you're,
going
through
a
an
audit
or
going
through
kind
of
different
compliance
frameworks,
is
build
a
map
of
how
the
application
communicates
and
since
we're
at
that
system
call
level,
we
can
do
that
for
you,
and
so
basically,
what
you
see
here
is
a
name
space
called
java
application.
B
We've
got
a
number
of
services
inside
that
application
and
we
can
then
spec
out.
You
know
the
labels
on
a
particular
deployments,
the
port
that
we're
communicating
on
traffic
wise.
The
way
traffic
is
flowing
through
the
application,
and
then
we
can
build
security
rules
around
how
that
traffic
should
flow.
So
in
this
case
the
default
is
that
everything
inside
the
namespace
is
okay.
Everything
external
to
the
namespace
is
not
okay.
That's
why
you
can
see
these
red
lines
versus
these
black
lines.
B
So
I
could
take
this.
I
could
download
the
pdf.
You
know
have
this
as
an
artifact
for
my
auditing
process
and
I
can
even
come
in
and
say
well
I
want
to
make
this
a
little
bit
different.
I
want
to
tweak
this
so
that
we
can't
we
can't
communicate
with.
I
can
go
to
my
egress.
I
can
come
find
the
tag
and
I
can
go
ahead
and
just
untick
it
and
if
I
come
back
to
my
topology
view,
we'll
see
that
that
line
then
goes
red,
so
we're
going
to
disable
that
communication
there.
B
This
is
what
I
want,
so
I'm
going
to
go
ahead
and
generate
that
topology
and
then
I'm
going
to
generate
a
policy
to
go
along
with
it,
and
I
can
apply
this
to
my
cluster
to
then
dictate
how
that
network
policy
is
implemented
right.
So
basically
saying
that
this
is
what
the
communication
should
look
like.
I
don't
want
it
to
look
like
anything
else
and
we'll
ensure
that,
with
this
particular
policy.
B
Yeah,
the
cystic
agent
runs
across
the
nodes
in
your
cluster
and
we
investigate
all
the
system
calls
that
are
coming
through
that
in
particular
node,
and
then
we
can
generate
these
views
based
off.
Those
calls
right
because
we
can
see
everything
down
to
the
headers
of
those
packets
and
then
be
able
to
reconstruct
the
way
something's
flowing.
B
B
B
If
I
do
it
from
the
monitor
perspective,
it's
a
little
bit
easier
to
see
as
well,
where
I
can
come
up
here
and
I
can
go
to
a
view-
that's
based
on
deployments
and
pods
and
effectively
what
this
does.
Is
it
changes
the
view
with
the
metadata
that
we
pull
in
and
lets
you
see
it
by
cluster
right,
so
it
could
be
on-prem
stuff.
It
could
be
cloud
things,
it
could
be
open
shift,
it
could
be
aro
right.
A
Cool
yeah-
and
we
didn't
chat
about
this
when
we
prep
for
the
show,
but
you
may
know
this.
If,
if
folks
have
multiple
clusters,
hundreds
of
clusters,
they
can
use
red
hat
one
of
red,
hat's
products
called
advanced
cluster
management
and
synthetic
was
one
of
the
first
companies
to
contribute
a
policy
to
the
governance
part
of
that
product.
And
what
that
means
basically
is
you
can
automate
the
installation
of
the
systick
agent
across
all
of
your
clusters?
A
B
That's
a
good
question,
and
upstream
falco
and
the
multi-cloud
manager
for
ibm
are
a
it's
the
it's
effectively
the
the
systig
secure
runtime,
and
that
is
the
same
as
kind
of
the
upstream
taco
runtime,
and
so
there
isn't
much
difference
there
like
most
things
that
are
kind
of
leveraging
an
open
source
project.
It's
likely
that
the
falco
rev
is
gonna,
be
a
little
bit
ahead
of
what
is
shown
up
in
mcm
or
in
the
assisting
solution.
B
A
A
B
Yeah
yeah,
no,
it's
it's
a
again.
It's
a
demo
environment
right,
so
we
do
all
the
bad
things
there
stuff
you
shouldn't
be
doing
in
production
things.
You
should
be
able
to
react
to
right.
Like
you
know,
we've
we've
got
policies
here
in
systig
that
kind
of
link
rules
together,
and
so,
if
it
comes
to
runtime
policy,
you'll
see
something
like
oh
gosh.
Where
is
it
here?
It
is
the
nist
policy.
B
So
if
you're
in
production
and
somebody
tries
to
say,
launch
a
privileged
container
and
they
shouldn't
right,
you
should
be
running
your
your
policy
in
that
cluster
is
to
not
run
containers
with
root
privilege.
You
can
actually
go
in
and
you
can
kill
off
the
container
or
stop
it,
and
these
interact
directly
with
the
runtime
api
beneath
it.
So
that
could
be
docker.
It
could
be
cryo,
you
know
whatever
that
is
or
the
other
fun
one
is
is
paws.
This
one
would
do
a
c
group
freeze
to
the
container
processes.
A
B
A
B
A
B
Want
to
try
to
keep
it
into
kind
of
the
more
monetary
metric-y
side
of
stuff
to
a
certain
degree.
I
mean
there's
other
things
in
here
too
around
you
know
scanning,
and
you
can
see
here
that
we've
got
events
around
rejecting
stuff
with
our
mission
controller.
So
there's
there's
all
sorts
of
stuff
to
integrate
in
systig
around
the
entire
life
cycle
of
your
applications
and
do
it
in
all
sorts
of
different
ways
like
we've
got
customers
who
leverage
us
in
their
ci
cd
pipeline
before
applications
ever
hit.
B
The
repo
we've
got
other
ones
that
look
into
the
repositories.
Specifically,
I've
got
one
customer
whose
entire
use
case
exists
around
their
customers
who
give
them
containers,
and
so
they
can't
control
the
cicd
pipeline.
But
then
how
do
they
protect
their
environment
from
what
might
contain
malicious
code?
And
so
they
use
our
admission
controller
to
do
all
of
the
admission
or
rejection
of
those
customer
applications
into
their
their
particular
cluster,
so
all
sorts
of
different
ways
to
kind
of
handle.
A
B
Yeah
yeah,
so
that
actually
is
in
this
posture
tab.
And
if
we
come
down
to
our
benchmark
tasks,
you
can
see
a
bunch
of
different
benchmarks
here
and
what
it
is
is
taking
things
like
the
the
cis
benchmarks
for
kubernetes
or
for
docker
for
openshift
or
for
the
gke
engine
kind
of
all
the
stuff
there
in
between
even
the
linux
benchmark
itself
and
just
make
sure
that
your
your
nodes
are
hardened
and
following
those
best
practices.
A
B
What
I
like
about
these
is
that
it's
it
gives
you
again
artifacts
to
give
to
your
auditor
right.
So
if
I'm
looking
here
at
the
cis
benchmark
for
docker,
basically
it'll
go
through
and
say,
here's
the
things
you're
doing
right
and
here's
the
things
that
you're
not
doing
as
per
that
check,
you
know.
So,
if
you're
not
doing
it,
what
is
the
check
about
you
know?
B
A
That's
right,
yeah!
Well,
let
me
let
me
give
the
audience
time
to
ask
any
questions
and
while
well
they
think
about
that.
I'm
going
to
share
this
last
one
thing
here,
which
everybody
has
probably
already
seen
from
the
beginning,
but
I'm
just
a
reminder
that
this
series
is
a
monthly
series.
We
do
streaming
shows
every
month.
So
look
on
the
calendar
for
devsecops
is
the
way
next
month,
as
we
mentioned,
is
remediation.
If
you
missed
any
of
the
months,
don't
worry
all
the
content
is
out
on
your
fingertips.
A
If
you
go
to
the
red
hat,
open
shift,
youtube
channel,
you'll,
see
all
of
our
devsec
ops
is
the
way
streaming
shows
go
to
redhat
catalog.redhat.compodcast
you'll
find
a
bunch
of
our
security
podcasts
and
then
just
some
reference
links.
If
you
want
to
try,
systig,
go
to
systig.com
and
hit
the
free
trial
or
red.http
devsecops
to
learn
more
about
what
we
do
out
here
at
red
hat
with
devsecops
our
point
of
view
and
all
the
partners
that
we
work
with
to
provide.