►
Description
With the emergence of Docker, three-tier application architecture is becoming legacy and container creation is becoming the new norm. There are still some challenges as this service is still growing. Developers must stand up a Docker host where they can deploy their images, and this means they need to account for infrastructure, networking, and security.
From a security perspective, containers change the attack vector and customers need to protect themselves. However, there is good news. The declarative nature of containers makes it easier with the right tooling to provide enhanced security that customers could not achieve in a three-tier architecture. Twistlock is one of those tools. In this session, Michael Withrow will give us an overview of container security issues and a walk-thru using Twistlock’s offering with applications deployed in containers on OpenShift.
Michael Withrow, Chief Architect & Director of Solution Architecture, at Twistlock. Michael recently joined Twistlock after spending eight years, and working on more than 150 deployments of Azure, at Microsoft.
A
A
These
sig
meetings
is
a
little
different,
we're
going
to
let
Michael
talk,
or
you
know,
20
or
30
minutes
and
give
a
demo
and
then
we're
going
to
open
it
up
for
a
conversation
with
everybody
who's
on
the
line.
You
can
ask
questions
in
the
chat
and
talk
amongst
yourself
in
the
chat
while
he's
talking,
but
once
he's
done,
talking
he's
taken
a
breath,
we're
gonna
turn
it
on
and
just
let
everybody
talk
with
Michael
and
ask
any
questions
that
they
might
have
so
without
any
further
ado.
B
Right,
Thank,
You,
Diane
I,
really
appreciate
it
and
thanks
everybody
for
attending
I.
Understand
time
is
money,
so
I
really
appreciate
it.
Alright.
So,
as
I
just
said,
my
name's
Michael
with
Rome
the
director
of
solution
architecture
here
at
twistlock.
So
what
do
we
do
as
a
company?
So
really
what
we're
focused
on
is.
As
you
look,
you
know,
you
have
the
doctor
ecosystem
and
you
have
enterprise
needs
I
mean.
Essentially
we
are
the
technology
that
really
fits
in
between
those
two
to
bridge
them
together
from
a
security
posture
perspective.
B
So,
looking
at
a
little
bit
of
the
vision
from
from
a
product
perspective
and
a
company
perspective,
you
know,
as
you
look
at
it,
the
value
proposition
for
containers
is
is
is
is
out
there.
You
know,
look
at
the
devops,
the
immutability,
the
statelessness
that
exists
from
a
containerized
ecosystem
perspective,
you're
we're
seeing
massive
adoption
across
the
globe.
Really
every
every
industry
pillar,
every
gyeo
is
a
massive
adoption
ring
this
going
on
from
containers.
B
Essentially
there
is
you
know,
I'm
taking
hey,
look
my
traditional
monolithic
approach
to
securities
and
can
I
take
that
and
apply
that
to
containers
right
and
then,
as
I
look
at
that
is,
is
containers
a
better
opportunity
for
security
or
less
or
whatever.
It
is,
and,
and
that's
a
lot
of
the
conversation
that
we
have
with
customer
after
customer
as
they're.
Looking
at
you
know,
production,
izing,
they're,
containerized
ecosystem.
The
reality
is,
as
you
look
at,
it,
containers
really
change
the
attack
vector
that
exists
for
your
application.
B
When
you
move
it
to
the
container
and
really
what
we're
talking
about
is
that
with
the
right
to
lling?
Essentially,
you
can
improve
this
carry
posture
of
that
application
by
moving
it
to
a
containerized
technology
and
I'll
kind
of
walk.
You,
you
know,
through
our
technology,
to
show
how
that
that
really
comes
true,
really
what
we're
talking
about
from
a
capabilities
perspective,
just
a
baseline
everybody
is
that
we're
essentially
talking
about
the
fundamental
characteristic
ADA
of
containers.
B
It's
getting
deployed
that
way,
so
very
declarative
in
that
nature,
and,
most
importantly,
essentially,
a
container
by
nature
is
immutable
right.
You
don't
have
agents
in
there
making
them
stateful,
essentially
they're,
stateless
and
immutable
in
that
particular
regard,
which,
like
said,
those
are
the
key
terms.
I
want
you
to
think
about.
Is
we
kind
of
walk
through
what
we
do
from
a
from
a
product
perspective?
B
So
when
you
look
at
it
as
well,
really
driving
that
point
home,
there's
there's
a
couple
of
key
security
advantages
that
exist
with
a
containerized
ecosystem
over
a
traditional
monolithic
right,
and
it
really
comes
down
to
the
automation
right.
So
so
heavy
automation,
integration
with
the
CI
pipeline
process,
maintenance
through
metadata
and
really
what
you
want
to
think
about
is
that
when
you
look
at
key
containerized
deployments
essentially
what's
happening,
is
that
essentially
a
traditional
monolithic
application
gets
broken
down
right
so
essentially
inside
of
a
monolithic
application,
say
it's
Reacher
application.
You
might
have.
B
You
know
three
nodes
in
there
representing
each
level
of
the
tier
and
across
each
of
those
nodes.
You
might
have
15
applications
in
there
right
and
that
essentially
makes
up
your
application
well
in
a
containerized
ecosystem.
You
wouldn't
have
those
three
VMs
you'd
actually
have
ten
containers
each
container,
representing
that
particular
application
right
as
it
ties
into
that
particular.
B
You
know
overarching
application
in
that
regard,
and
essentially
each
one
is
autonomous
in
that
regard
and
individually
updated
without
you
know,
impact
across
the
other
one
across
that
tier,
and
so
when
you
look
at
traditional
monolithic
right
essentially
what
you're
looking
at
in
that
regard
is
that
you
have
heavy
dependencies.
You
have
you
know,
you
have
agents
all
these
kind
of
things
like
that.
So
now,
when
you
talk
about
upgrades
right
essentially
now
you
have
to
go
through
and
you
have
to
do
regression
testing.
B
You
have
to
go
through
CMDB
boards
get
downtime
all
these
kind
of
things
like
that.
You
have
to
work
through
right
off,
not-so-good
perspective.
So
when
you
look
at
it
right
now
start
pulling
back.
What
are
some
of
the
security
challenges
that
that
containers
actually
bring
to
the
mix
as
well,
right
and
so
commodities
of
scale
is
the
biggest
thing
right.
B
So
you
have,
you
know,
legacy
images,
those
kind
of
things
like
that
now
I'm
on
version
100
of
this
image,
but
I've
still
got
one
through
99
that
exists
in
this
environment.
Those
kind
of
things
like
that,
so
the
VM
sprawl.
You
know
the
sprawl
conversation
is
kind
of
come
back.
When
you
talk
about
containers
and
obviously
a
heavier
rate
of
change.
B
Instead
of
with
traditional
VM
environments,
you
might
see,
you
know
a
say,
a
quarterly
or
a
biannual
II
type
of
update
of
that
application,
whereas
with
containers
daily
weekly
updates
are
our
commonplace
in
that
particular
regard,
so
a
higher
rate
of
change
across
that
ecosystem
and
then
essentially,
the
security
responsibility
moves
right.
So
now
it's
essentially
further
upstream
now
it
is
in
the
hands
of
the
developer
and
not
necessarily
falls
in
the
infrastructure
team
right.
B
So
in
that
regard,
do
you
think
application-specific
right
and
not
that
that
edge
based
security
conversation
that
typically
fell
on
the
infrastructure
team,
and
now
it's
making
security
an
entire
stream
based
responsibility
on
where
developers
are
typically
last
the
line
when
you
talked
about
security.
So
now,
when
you
look
at
it
right,
essentially,
when
you
look
at
containers,
what
is
that?
What
is
the
value
prop
of
containers
right
essentially
by
nature?
A
container
is
secure,
I
mean
it
is
portable
right,
so
essentially,
I
mean
I.
B
Do
get
away
from
that
hypervisor
conversation
that
that
vendor
lock-in
to
X,
Y,
&
Z,
maybe
you're
running
a
multi
cloud
right,
maybe
you're
running
you
know
in
a
hybrid
cloud,
a
public
cloud
or
whatever
it
is.
Essentially,
you
know
when
you
look
at
our
technology.
Essentially,
we
provide
that
portability
as
well,
because
essentially
not
only
does
our
technology
protect
the
containerized
ecosystem,
but
essentially
our
technology
is
containerized
technology
as
well
right,
and
so
essentially,
what
that
means
now
is
think
of
a
REST
API
based
product
that
really
hooks
into
the
entire
ecosystem.
B
B
Essentially
we
can
provide
a
single
pane
of
glass
into
that
environment
and
when
you
look
at
our
product,
essentially
it's
a
lifecycle
management
based
product
really
providing
cradle
to
scale
security
right,
so
really
starting
in
that
CI
pipeline
process,
maybe
using
Jenkins,
maybe
using
drone,
maybe
using
bamboo
whatever
that
might
be
from
that
particular
regard.
Essentially,
we
can
integrate
deeply
in
that
environment
so,
as
those
images
are
getting
built
before
they
get
to
the
registry
before
they
get
attached
to
a
deployment
script
and
pushed
out
into
pods
those
kind
of
things
like
that.
B
We're
gonna
integrate
at
that
particular
point
and
then,
as
it
does
get
pushed
into
a
registry,
and
then
now
you
have
it
in
runtime
out
in
a
pod.
For
now,
from
the
perspective,
we're
gonna
provide
a
security
posture
of
that
entity,
all
the
way,
through
all
the
different
steps
that
is
going
to
take
in
its
lifecycle,
and
we
do
all
this
without
you
having
to
give
up
any
of
your
control.
B
Essentially
all
the
data
lives
in
your
environment,
so,
like
I
said
before,
maybe
you
have
a
private
cloud:
were
you
deploy
to
open
ship
in
that
private
cloud?
And
essentially
now
you
would
drop
twistlock
into
that
open
shift
environment
which
is
in
your
private
cloud.
All
the
analysis,
that's
taking
place
from
a
security
perspective
is
happening
in
your
environment,
so
we
don't
pull
anything
out
to
in
to
assess
or
analyze
your
particular
environment.
We
have.
We
have
many
ways
that
we
can
support.
Like
I
said:
I've
talked
about
private
and
public.
B
B
What
do
we
do
from
a
product
perspective?
Essentially,
as
I
alluded
before,
we
are
lifecycle
management,
so
build
through
run
and
and
one
of
the
key
things
that
we
do
and
really
where
most
customers
reach
out
to
us
is
around
the
vulnerability
management
right,
so
so
think
of
integrating
into
the
building
I
pipeline
process,
where
images
are
built,
we're
gonna
assess
and
actually
restrict
the
state
of
that
image
based
on
thresholds.
B
Those
kind
of
things
like
that
and
then,
as
that
image
moves
upstream
into
the
registry
right,
we're
gonna
assess
the
vulnerability,
State
the
malware
State.
You
know
the
threat
state
of
that
image
as
it
exists
in
the
registry
as
well,
and
then
you
know
essentially
now
downstream
and
now
you're
running
that
inside
of
a
pod
inside
of
your
openshift
environment.
We
can
tell
you
the
vulnerability
state
of
that
image
and
actually
restrict
that
image,
actually
restrict
that
vulnerability
from
running
inside
of
your
OpenShift
pod
as
well.
B
From
that
triplet
perspective,
we
also
tie
in
compliance
right
so
think.
C
is
benchmarks
for
containers
industry
standards
around
comply.
Those
kind
of
things
like
that
we
can
tie
into
that
environment
as
well
and
restrict
you
know,
say
you
have
a
security
posture.
You
want
to
maintain,
and
essentially
now
someone
you've
done
a
good
job
of
building
a
clean
image.
B
Now
someone
tries
to
run
that
image
say
as
route
as
an
example
right,
but
you
don't
want
that
to
run
his
route
or
they
expose
a
certain
port
or
SSH,
or
something
like
that
now,
when
they
run
it.
We're
gonna
assess
that
state
from
a
compliance
perspective,
see
that
it's
outside
of
the
compliance
posture
that
you're
trying
to
maintain
and
restrict
that
image
from
being
run
inside
of
your
pod
right
from
a
certain
perspective,
and
then
we
also
tie
in
some
access
control
mechanisms.
B
As
you
look
at
OpenShift
on
there's
a
couple
different
ways
that
you
could
integrate
from
magical
perspective
and
then
rounding
it
out
from
a
product
perspective,
we
tie
in
anomaly
based
detection
across
your
running
entities
through
our
runtime
defense
mechanisms,
so
pulling
the
covers
back
a
little
bit
further.
What
you
want
to
think
about
is
that
essentially,
how
we
work
from
a
product
perspective
is
that,
first
and
foremost,
we
want
to
generate
a
bill
of
materials
off
of
that
image.
B
B
Have
a
shell
script
would
call
out
that
that
SH
file
and
then
it
would
basically
on
build
it,
would
scan
and
you'd
pump
out
those
results
from
that
trigger
perspective,
maybe
the
first
time
we
see
that
image
is
actually
in.
You
know,
upstream
in
your
registry
right
I
said
as
long
as
there's
a
v1
or
v2
based
registry.
We
can
integrate
it
with
it
right.
So
you
know.
B
Red
Hat's
registry
looks
at
all
that
all
the
industry
registries
we
can
integrate
with
it,
and
so,
as
that
image
gets
moved
from
your
CI
pipeline
process
into
that
registry.
You
know
it's
been
there
for
a
while
right,
so
we
can
assess
the
state
of
that
image
as
well
as
it
as
internet
registry,
and
really
what
you
want
to
think
about
is
how
we're
doing
that
is.
Essentially
what
we're
doing
is
simply
enough.
Conducting
a
static
image
analysis
off
of
that
JSON
file
are
really
understanding.
B
You
know,
what's
the
base
layer
right,
is
it
Debian
based
Alpine
based
as
an
example,
you
know?
What's
the
framework,
are
you
building
a
java
app
or
a
ruby,
app,
or
something
like
that,
and
then
in
that
readwrite
layer
that
sits
on
top?
What
is
what
is
your
custom
code
set
right?
What
are
the
files,
your
snipping
sticking
in
there?
What
are
the
system
calls
those
kind
of
things
like
that,
we're
kind
of
looking
in
there?
B
Everything
sits
in
your
environment
is
that
we
want
to
detect
the
CBE's
the
zero
days
and
the
malware
that
exists
against
the
entities
that
we
defined
in
that
image
Ryan
to
be
a
little
bit
more
trans
transparent
in
that
regard,
you
think
of
packages
right,
so
the
package
manager
in
that
particular
regard
we're
gonna,
look
through
and
go
through.
The
packet
is:
maybe
you
have
a
tar
file
in
there,
where
you're
gonna
basically
expose
a
package
or
install
a
package
to
that
tar
file.
B
Those
kind
of
things
like
that
we
can
see
that
inspect
that
and
then
now
we've
we've
stashed
that.
So
now
we
know
hey,
look.
You
have
these
packages
as
part
of
the
image,
whether
that
since
they're
installed
through
package
manager
or
through
some
power
file
in
that
particular
regard,
and
so
now,
as
that
image
goes
to
its
lifecycle.
Essentially
now
we
bring
in
a
real-time,
intelligent,
CVE
streaming
service
will
repulse
my
wide
range
providers.
Think
of
all
the
different
operating
systems,
all
the
different
languages
from
nist
GIS
think
the
NVB
database.
B
B
We
have
partnerships
with
some
IP
and
malware
sites
as
well
to
pull
on
that
IP
and
malware
data,
and
then
we
have
some
pretty
pretty
aggressive
machine
learning,
algorithms
as
well,
that
we
kind
of
pump
in
as
you
as
you
kind
of
go
through
that
that
lends
to
the
lifecycle
right
because
now,
from
a
scenario
perspective,
you
built
a
Java
based
image
that
has
W
get
and
SSH
exposed
or
what
it
is
from
magical
perspective.
On
that
that's
your
get
your
deploying
out
as
it
went
through
the
CI
pipeline
process.
B
We
assess
the
state
of
that
and
through
the
threshold
based
process,
you
know
we
got
allowed
to
get
posted
to
the
registry,
but
obviously
now
it's
been
in
the
registry
for
three
weeks
right.
So
so
now,
over
those
three
weeks,
of
course,
you
know
these
components
have
lit
up,
and
the
package
manager
is
totals
that
there's
vulnerabilities,
we're
gonna
pump
into
the
environment
and
light
up
those
those
components
across
that
ecosystem
like
a
Christmas
tree
in
that
particular
regard.
B
But
essentially
we
don't
even
stop
there
from
that
to
the
perspective
so
say
whether
or
not
you
have
it
in
the
CIP
pipeline
process
that
images
in
the
registry.
It's
been
there
for
a
month
or
now
you
have
a
running
container,
that's
been
running
for
six
months
right,
that's
where
the
CVE
service
is
going
to
come
in
and
add
as
a
as
a
package
becomes
vulnerable,
essentially
we're
gonna.
We
already
know
from
a
signature
perspective
where
that
package
transpires
across
your
ecosystem
and
essentially
all
those
images.
B
All
those
images
attached
to
containers
attached
to
pods
we're
gonna
light
that
up
right
and
then
taking
it
further.
We
actually
have
the
ability
to
actually
block
those
vulnerabilities
as
well,
whether
it's
on
a
you're
trying
to
build
an
image
and
when
someone
tries
to
run
that
image
think
image
integrity
in
this
particular
regard.
So
you
have
a
scenario
where
hey
look,
you've
built
a
clean
image
right
I
mean
now
you
have
a
clean
image
on
build,
but
that
image
has
now
been
living
in
the
registry
for
three
weeks.
B
So
obviously,
over
the
three
weeks,
a
couple
of
the
packages
now
have
vulnerabilities.
So
now,
when
someone
tries
to
do
a
deployment
off
of
that
image,
essentially-
and
you
have
the
policy
set
to
block-
essentially
we
will
strict
that
image
from
being
deployed
into
a
pod
because
it
has
vulnerabilities
in
it.
B
So
the
idea
from
a
DevOps
perspective
was
that
image
would
get
thrown
away
because
you
don't
upgrade
or
patch
containers
right,
you
throw
that
container
away
and
you
deploy
another
container
in
its
place
or
another
image
in
its
place,
which
doesn't
have
that
vulnerability
that
someone,
your
admin
or
whatever
can
do
it
open
ship
deployment
off
of
into
your
environment,
and
if
you
have
an
open,
running,
OpenShift
pod,
right,
I.
Think
of
us
as
a
proxy
that
that
you
know
works
through
the
doctor
socket
in
that
particular
regard.
B
So
if
we
need
to
restrict
basin,
you
have
policy.
If
you
don't
want
to
have
us,
this
application
is
very
critical
to
you.
You
don't
want
to
have
it
hat
out
and
running
with
vulnerable
vulnerabilities,
and
so
essentially
you
could
move
the
policy,
the
block
and
essentially,
in
that
regard
we
will
restrict.
If
now
you
have
Java
in
that
image
and
all
of
a
sudden
Java
lights
up,
essentially,
we
would
restrict
that
image
right
so
think
of
in
that
regard,
we
would
kill
that
image,
because
essentially
it's
adhering
to
containerized
best
practices.
B
You
know
if
a
container
is
anomalous
has
an
anomaly
in
it
or
a
vulnerability
in
it.
You
don't
patch
it
upgrade
it
you
throw
it
away
and
build
another
one
right.
So
essentially
we
can
talk
about.
You
know
what
that
means
from
a
scenario
perspective,
but
we
allow
you
from
a
product
perspective
to
one
be
alerted
to
the
factors
of
vulnerability
and
if
you
choose
to
restrict
that
vulnerability,
so
this
is
what
that
CI
pipeline
process
looks
like
essentially,
you
know,
think
of
a
you
know.
B
A
developer
is
gonna,
be
building
an
image
I
injecting
in
the
pipeline.
We're
gonna
go
through
and
the
CI
tool
is
going
to
notify
us
via
the
API
or
the
plugin.
They
hey,
look.
A
span
needs
to
be
initiated
will
conduct
an
ad
hoc
scan
and
publish
the
results
back
to
that
CI
pipeline
process
and
then
essentially
through
there,
you
can
do
with
you
know
a
threshold
based
failure
right
so
think
low,
medium
and
high
from
a
CBE
scoring
perspective.
B
So
what
you
would
say
so,
maybe
you
have
offshore
developers
or
partners
or
giving
you
images.
You
could
pump
them
through
this
process
and
see
if
you
even
want
to
check
them
into
your
registry.
Maybe
it's
a
trusted
registry
from
that
trooper
perspective
and
then
so
think
of
a
scenario
where
maybe
the
the
step
to
build
the
image
is
step.
Three
step
four
would
be
for
us
to
scan
it
step.
Five
would
be
for
us
to
publish
the
results
and
step.
Six
would
be
for
you
to
push
it.
B
You
know
down
to
your
registry
or
to
your
downstream
registry,
whatever
that
mechanism
might
be
compliance,
so
here
I'll
kind
of
kind
of
grease.
Through
this,
we
can
talk
to
this
a
little
bit
more
as
we
kind
of
get
through,
but
the
idea
here
is
that
we
can
tie
in
CIS
benchmarks
for
containers
and
we
can
also
tie
in
all
of
your
industry
standards.
Maybe
you
want
to
have
application
specific
configurations
that
you
want
to
adhere
every
time
we
deploy.
It
has
to
be
deployed
this
way.
Every
time
I
deploy.
Tomcat
has
to
be
deployed.
B
This
way
we
can
enforce
that
from
a
compliance
perspective
through
data
sets,
you
upload
the
data
set
to
us
and
we
allow
in
a
very
granular
fashion,
for
how
you
want
to
enforce
that
compliance
posture
right
so
through
actions
right,
so
the
action
might
be
I
want
to
be
alerted
when
this
particular
configuration
is
tripped.
Maybe
you
say
that
hey
look
or
maybe
it's
an
application-specific
configuration,
think
hey
look.
I
have
a
tomcat
website,
I
want
to
make
sure
that
every
single
time,
its
deployed
its
deployed
over
80
43
and
not
443
as
an
example.
B
So
now
developer,
a
new
developer
comes
in
I
kind
of
missed
that
part
of
the
the
common
engineering
criteria.
So
when
they
deployed
it
out,
essentially
they
tried
to
turn
it
on
over
443
you'd.
Have
a
setting
in
here
said:
hey
look!
If
this
image
is
running
off
of
443,
restricted
right,
I
want
to
block
that
configuration,
take
it
back
to
the
developer,
to
move
it
over
to
80-43,
and
now
they
can
actually
do
a
deployment
off
of
that
I
mean
we
also
in
here
also
tie
in
image
integrity
right.
B
So
what
you
want
to
think
about
here
is
think
cryptographically
certifying
images,
so
you
would
have
a
scenario
where
hey
look
one
as
I'm
building
that
image
now
I
know
that
that
image
is
trusted,
so
I
want
to
make
that
image
trusted
so
I'm
gonna,
integrate
with
content,
trust
and
and
an
Associated
Shaw
value
as
a
tag
with
that
image
on
push,
maybe
through
my
CIA
pipeline
process
or
whatever
it
is.
So
you
would
take
your
in
this
scenario.
B
Take
your
Red
Hat
registry
and
associate
that
with
twistlock
as
a
trusted
registry,
and
then
we
would
in
turn
associate
that
with
policy
and
say:
hey!
Look
now
that
you've
built
this
gold
image.
Essentially,
now
what
we're
gonna
do
from
a
process
perspective
is
cryptographically
certify
that
and
say
that
only
these
people
can
pull
that
cryptographically
a
certified
image
and,
more
importantly,
those
people
in
that
group
can't
backdoor
or
go
around
that
policy
and
as
an
example,
they
don't
want
to
use
your
trusted
image.
They
want
to
go
to
dr.
B
IO
and
pull
the
Swiss
cheese
version
on
that
image.
We
would
restrict
that
from
a
process
perspective,
so
access
control-
you
know
you
look
at
OpenShift.
Has
some
capabilities?
Is
there
really?
The
key
thing
you
want
to
think
about
here
from
a
product
perspective?
Is
that
there's
a
lot
of
ways
we
can
complement
in
that
particular
regard,
but
really
what
we're
kind
of
talking
about
in
this
particular
regard
is
really
providing
the
detailed
audit
trail
off
the
back
end
off
of
every
single
transaction
that
goes
across
that
dr.
B
Damon,
so,
whether
it's
a
user
based
access
mechanism
or
whether
it's
a
privilege,
think
pseudo
or
root
in
a
particular
regard.
We
provide
that
forensic
trail
of
what
transpired
across
that
Damon
as
we
kind
of
go
through
and
now
you
know
now.
You
have
running
entities
right,
and
so
essentially
we
round
out
the
product
with
our
anomalous
based
detection
and
really.
The
idea
here
is
that
we
really
bring
what
we
did
and
vulnerability
management
where
we
did
that
static
image
analysis.
B
You
kind
of
see
that
here
on
the
left,
often
that
tricular
perspective,
and
then
we
plus
that
up
with
a
launch
time
metadata
right
when
you
kind
of
now
you
deploy
that
pod
and
now
you
have
that
running
entity.
We're
gonna,
look
at
that
launch
time
metadata
through
that
we're
gonna,
detect
certain
things
right
so
think
applications
specific
detection
here
for
our
first
leg
of
machine
learning
right
and
so
what
we're
gonna
we're
doing
here.
This
is
very
application.
Centric
Hey,
look
we
detect
httpd.
This
must
be
an
Apache
file.
B
Here,
let's
go
find
the
config
file
figure
out
what
ports
are
associated
with
this
particular
deployment,
or
this
might
be.
Let's
go
look
at
these
files
and
found
this
SH
file
or
whatever
it
might
be
in
that
regard.
Maybe
it's
Tomcat
or
Redis,
or
something
like
that.
Essentially,
that's
what
the
machine
learning
there
is
looking
for
application,
specific
tags
and
then
pulling
that
out.
So
because
the
idea
from
a
product
perspective
is
we
want
to
build
a
predictive
model
because
we're
taking
advantage
of
the
declarative
nature
of
containers
and
so
by
nature.
B
Hey,
look,
you're,
saying,
hey,
look!
The
purpose
of
this
container
is
to
run
Redis
right,
so
we're
gonna
grab
all
that
Redis
specific
configuration
and
we're
gonna
whitelist
that
topology
out
the
key
thing
about
this.
Is
that
essentially
we
do
that
completely
automatically
on
the
back
end
from
a
product
perspective,
and
all
you
did
from
a
product
perspective
was
tell
us
where
your
images
were.
In
this
scenario,
all
you
would
do
is
drop
twistlock
into
your
open
shift
environment
and
we
would
take
it
the
rest
of
the
way.
B
We
would
assess
the
vulnerability
State
and
we
will
provide
the
anomalous
base
state
of
your
entities
as
they're
running,
because
we
already
know
what
they
should
be
running,
because
we
built
a
predictive
model
off
of
the
images
that
are
running
inside
of
your
OpenShift
ecosystem
and,
like
I
said.
The
value
prop
here
is
that
we
did
that
completely
automatically
without
you
having
to
do
anything
from
a
product
perspective,
and
then
we
also
introduced
a
feature
set.
We
call
a
twist
lock
advanced
threat
protection,
which
is
a
deeper
set
of
machine
learning.
B
Algorithms,
so
here
think
of
a
scenario
where
hey
look,
you've
deployed
this
image
or
this
container
into
openshift
right
and
so
now,
there's
OpenShift
normal
processes
that
run
on
the
back
end.
If
we
were
auditing
every
single
transaction,
essentially
what
that
would
mean
is
that
essentially
we're
generating
a
lot
of
white
noise,
false
positives
in
that
regard
of
traffic
traversing
across
your
environment.
So
through
that,
we
would
see
it,
we
would
detect
OpenShift.
B
No,
no,
because
we
run
openshift,
we
pump
it
through
our
machine
learning
algorithms,
and
we
see
that
these
are
the
normal
processes,
and
then
we
include
those
in
the
white
list
for
that
particular
application.
So
now
what
you're
left
with
from
a
resultant
perspective,
is
really
those
only
true
anomalies
that
you
have
to
react
off
of
right
and
then,
essentially,
that's
ever
evolving.
So
as
Diane
was,
we
were
talking
about
before
you
guys.
Just
open
shift
just
released
3.3.
B
So
if
you
go
from
three
to
two
three
three
there's
some
changes
in
there
and
really
what
that
means
from
our
perspective
is
that
we're
gonna
pump
in
3
1,
3
2
3
3
into
our
machine
learning.
Algorithms.
Look
at
that!
Look
at
that
open
shift
environment
in
a
running
state
and
grab
all
the
signatures
off
of
that
and
then
pump
it
through
our
intelligent
stream
service.
So
essentially
you
get
the
benefit
of
that
in
a
continuous
state.
B
Alright,
so
I'm
gonna
show.
Let
me
skip
time
to
limit
it.
I
would
walk
you
through
a
little
bit
deeper,
but
essentially
how
we
bring
this
home.
This
kind
of
gets
into
the
demo.
From
that.
To
the
perspective,
the
idea
from
an
architectural
perspective
as
I
was
alluding
to
before
we
are
just
a
containerized
based
infrastructure.
So
on
the
left
is
our
intelligent
stream
service.
I
was
talking
about
see
all
the
different
cv
information.
You
know
we're
pulling
from
the
Red
Hat
ovals
oval
feed.
You
know
from
NIST
and
CIS,
you
know.
B
B
Is
your
environment
right,
like
I,
said
whether
it's
a
public
cloud,
a
hybrid
cloud,
a
private
cloud,
maybe
you're
deploying
around
just
physical
servers.
The
idea
is
that
you
have
a
docker
daemon
that
in
that
regard,
we're
gonna
give
you
an
SH
file
which
has
two
tar
files
in
there,
one
for
our
console,
one
for
our
defender.
You'll
do
a
docker
run
off
of
those
so
to
speak
and
basically
deploy
them
as
containers
on
top
of
your
docker
Damons.
B
In
whatever
capacity
they
might
be
in
right,
simply
enough,
we
have
the
console
is
an
Alpine
based
image
running
a
node.js
console
with
the
database
in
there
is
where
you
obviously
configure
all
of
your
policies
out-of-the-box.
Essentially
we
have
all
the
policies
turned
on
and
set
to
alert
right
so
think
of
it
as
a
as
a
starting
point.
A
guideline
really
we're
thinking
about
it
from
a
time-to-market
perspective.
So,
essentially
you
know
out-of-the-box.
B
All
you
have
to
do
is
basically
deploy
our
product
in
your
environment
and
then
tell
us
where
the
registry
is
and
tell
us
where
your
containers
are,
and
essentially
we'll
started,
assessing
that
right,
but
really
we're
just
alerting
in
a
particular
perspective
that
maybe
you
have
a
PCI
based
application
or
something
a
a
certain
application
that
has
PII
data
you're
really
worried
about.
Maybe
you
want
to
build
a
policy,
that's
very
specific
to
that
application
and
move
that
to
block,
because
you're
really
worried
about
you
know
the
security
from
that
to
application.
B
We
allow
you
the
granularity
to
segregate
out
your
applications,
your
containers,
your
images,
those
kind
of
things
like
that,
like
I,
said
you'll
suck
in
your
users
in
groups.
We
don't
really
care
what
kind
of
identity
you
have
to
basically
provide
access
control
if
you're
using
some
other
access
control
mechanism.
We
integrate
with
that
as
well.
Complement
I,
like
I,
said
providing
those
audit
trail,
those
kind
of
things
like
that,
and
then
you
know
your
cluster
management
right.
So
obviously,
kubernetes
is
a
native
capability
for
us.
B
It's
the
same
thing
since
openshift
sits
on
top
of
that.
That's
where
the
tight
integration
that
happens
from
our
perspective.
So,
as
you
lay
that
environment
down,
we
just
implement,
we
just
integrate
with
the
docker
socket
in
that
regard
and
function
as
a
proxy
in
that
topology.
But
now,
as
you've
done,
that
you
build
out
all
your
policy,
the
idea
is
that
you
cache
that
policy
on
the
defender,
the
defender,
wears
multiple
hats
in
this
environment,
so
think
across
your
openshift
deployment.
This
would
go
on
all
of
your
slaves
right
from
that
trick.
B
The
perspective
as
you
as
you
kind
of
go
across
so
maybe
you
have
like
in
my
demo,
I'll
show
right
if
I
get
in
this
I
basically
have
a
three
node
kubernetes
cluster
with
the
manager
and
two
slaves
in
that
regard,
so
deploy
the
defender
across
that
apology
and
so,
as
I
start
deploying
pods
into
that
entity.
We're
gonna
start
assessing
the
state
of
those
pods
inventory
and
then
assess
the
state
of
what
we
discovered
in
that
inventory.
B
It's
kind
of
how
it
works
so
really
that
defender,
unlike
said,
is,
is
one
for
configuration
management
assessing.
What's
there
providing
that
inventory
data
enforcing
the
policies
that
the
console
has
set
and
then
providing
an
audit
trail
off
of
all
the
transactions
that
happen
across
that
daemon,
regardless
of
what
what
level
of
transaction
they
are
right,
so
think
of
a
scenario
where
hey
look,
you've
done
your
due
diligence
and
and
limited
pseudo,
often
magical
perspective
and
built
in
all
your
access
control
policies
for
all
the
OSI
commands.
In
that
particular
regard.
B
Now
an
admin
tries
to
run
an
OCC
policy.
They
get
an
access
denied
from
matching
their
perspective.
What
is
a
normal
admin?
Do
they're
gonna
run
a
pseudo
OSI.
You
know
in
that
particular
perspective,
to
try
to
scale
that
out
and
if
they
do
that,
essentially
we've
got
them
from
forensic
perspective.
We
would
detail
out
that
from
a
forensic
trail
perspective.
B
So
essentially
you
know
this
is
the
easiest
way
that
you
would
look
at
a
fanatically
regard.
You
know,
hey
look,
you
know
you
have
an
orchestration
manager.
You
know
you
have
your
your
doctor
engine
down
with
the
orchestration
agent
in
a
particular
regard.
We
just
integrate
those
defenders,
in
that
particular
perspective
through
the
orchestration,
if
use
and
access
control,
but
if
you're
just
using
vulnerability
management
runtime
defense.
B
All
right
so
as
we
go
through,
so
this
is
our
twistlock
console
from
maps
with
the
perspective.
So
what
you're
kind
of
seeing
here
is
is
it's
here:
I
have
a
really
simple
openshift
deployment
right
with
it,
with
a
Red,
Hat
console
and
node
1
and
node
2
in
this
particular
regard.
I've
already
deployed
twist
lock
on
that
topology
and
let's
set
out-of-the-box
twist
lock
is
already
you
know,
starting
to
assess
the
images
looking
at
the
risk
state
of
the
containers
that
are
part
of
that.
You
know.
Look
at
the
access
violations.
B
The
system
calls
the
process
violations
network
file
system
violations
that
exist
across
this
topology.
The
idea
is
that
you
know
first
and
foremost,
maybe
you
know
through
part
of
your
opus
of
deployment.
You
have
a
registry
right,
you'd,
integrate
and
in
the
registry
automatically
the
perspective
and
then
now
it's
essentially
a
resultant
of
of
your
configuration
right
so
from
a
flow
perspective.
What
you
essentially
have
is
we've
really
broken.
The
UI
into
three
buckets
first
and
foremost,
is
configure
here.
B
B
You
know,
essentially,
you
would
talk
with
those
on
so
regardless
of
whatever
orchestration
you
have,
you
would
tweak
the
config
file
and
then
you
would
like
that
that
capability
up,
we
have
a
couple
of
different
ways
to
deploy
the
defender,
and
essentially
the
native
way,
is
right
through
a
curl
command.
You
would
run
it
directly
on
your
slave
I'm
inside
your
kubernetes
cluster,
and
so
this
is
a
good
point
to
kind
of
pause
and
talk
about.
B
We
do
have
a
large
Bank
of
customers
that
are
already
running
open
shift
and
one
of
the
things
that
we're
doing
from
a
product
perspective
is
going
to
make
the
we're
gonna
generate
some
deployment
scripts
for
twistlock
inside
of
the
OpenShift
environment.
So
it's
not
just
you
know
a
native
install,
it's
actually
a
managed.
B
The
inside
of
your
Orchestra
OpenShift
environment
so
essentially
that'll
be
we're
about
two
to
two
four
months
out
from
having
that
capability
out,
but
essentially
in
the
inner
I'm,
essentially
think
of
it
as
a
manual
deployment
inside
of
your
open
shift
apology
and
then
once
we
get
the
deployment
script
so
it'll
be
really
tie
into
the
you
know
the
full
capabilities
of
the
open
shift
apology,
but
the
idea
is
that
hey
look
here,
I
have
those
notes
and
I've
kind
of
scaled
out
the
OpenShift
environments.
On
this
particular
regard.
You
know
we
have
the
ability.
B
So,
as
you
go
for
say,
like
said
you're
doing
access
control,
you
were
deploying
the
master,
but
you
want
to
do
vulnerability,
management
and
compliance,
and
you
know
runtime
defense.
You
would
use
that
the
node
and
that
that
particular
perspective,
but
you
have
those
kind
of
deployed
out
I'm,
not
too
clear
capability.
Here's
where
you
start
building
out
policy,
so
think
kubernetes
in
this
regard,
which
kind
of
ties
in
and
the
OSI
commands
in
that
particular
regard.
B
But
the
idea
is
that
hey
look
here,
I
have
all
the
API
calls
and
I
can
get
very
granular.
You
know.
Do
I
want
to
allow
or
deny
them
access
to
those
api's
and
here's
that
level
of
granularity
I
was
talking
about.
You
can
start
building
out,
hey,
look:
here's
application,
a
here's
application,
B,
maybe
I,
segregated
dev
level,
maybe
I,
segregated,
staging
or
prod
those
kind
of
things
like
that.
I
start
building
out
policies
that
line
up
to
that
and
then
I
start
segregating
out.
B
Who
can
do
what
and
then
audit
trail
off
the
back
end.
So
from
a
trust
perspective,
you
know.
The
key
thing
is:
is
you
know
vulnerabilities
right,
so
hey
look,
here's
the
vulnerabilities!
What
I
can
do
is
hey,
like
maybe
I'm,
building
a
java-based
application,
so
simply
enough
and
then
by
default
you
see
that
set
to
alert,
but
maybe
I
want
to
tweak
that
to
block
those
kind
of
things
like
that
from
a
product
perspective
here
in
compliance
we
actually
go
through
and
we
have
all
the
CIS
benchmarks.
B
So
as
an
example,
one
of
the
things
that
I
wanted
to
show
was
a
real,
quick
demo
for
you
guys
so
all
kind
of
restrict
limit
memory
usage
on
a
particular
application
think
buffer
overflow.
Those
kind
of
things
like
that
and
now
five
ten
off
not
to
perspective
I'm
gonna,
set
it
to
block
and
I
say
that
out
from
a
policy
perspective,
so
I'll
kind
of
toggle
back
from
natural
perspective.
So
now
I
have
this
host
here
from
night
perspective.
So
now
what
I'm
gonna
do
is
simply
enough.
I'm
gonna
try
to
build
another
app.
B
B
With
row,
six
not
to
the
perspective,
and
so
now
as
it's
going
through,
what
we're
gonna
see
is
when
it
gets
to
that
point
essentially,
we'll
see
a
note
in
here:
I'll
just
do
a
refresh
and
essentially
you'll
see
what
we
come
in
and
block
that
particular
perspective
and
see.
There's
a
sexual
pole.
Now
I
was
trying
to
do
a
container,
create
it
started,
and
essentially
that's
gonna
get
blocked
from
a
snare
perspective
right
as
we
go
through
I,
just
kind
of
waiting
for
that
to
catch
up.
B
Alright
I'll
give
that
a
second,
but
the
idea
is
that,
essentially
now
we
have
that
blocking.
So
as
that
deployment
happens,
essentially
what
you
want
to
think
about
is
when
gets
to
the
point
where
it
actually
does
that
actual
deployment
off
that
pod
when
it
goes
through
that
call
goes
through
the
daemon.
We're
gonna
pick
that
up
through
the
socket
and
assess
that
image
and
see
that
has
vulnerabilities
and
restrict
that
from
being
done
right.
B
So
obviously,
every
time
the
pod
tries
to
push
that
every
time
the
deployment
scripts
try
to
push
that
into
the
pod.
We're
gonna
restrict
that
right,
so
openshift
is
gonna
continually.
Try
that
obviously
right
so
we're
gonna
block
that
every
single
time
in
that
particular
regard
until
you
basically
pull
that
out
right.
B
So
what
I'll
show
from
a
scenario
perspective
is
that
hey,
look
you've
basically
attached
this
image
and
then
simply
enough
I
can
remove
that
vulnerability,
as
you
can
see
that
deployment
kind
of
going
through
so
we'll
kind
of
let
this
catch
up,
and
it's
gonna
make
a
liar
out
of
me.
So
it's
created,
it
started,
still
started
in
a
particular
regard.
I'm
kind
of
waiting
for
it
to
catch
up
from
absolutely
respect,
then
I'll
show
cuz.
B
So,
but
essentially
what
I'm
getting
at
is
that
essentially,
when
it
gets
to
the
point
where
it's
actually
building
the
container
see
it
started,
the
container
wait,
maybe
I
didn't
have
the
policies
set
was
actually
started.
The
container
in
that
regard,
maybe
I,
missed
setting
the
policy.
Let's
do
that
so
I
have
oh
I
know
why
I
did
that
because
I
did
on
the
wrong
policy.
So
let
me
do
let
me
do
five
ten.
B
Let
me
set
that
the
block
and
then
let
me
save
that
and
let
me
toggle
this
one
and
go
to
five
ten
and
turn
that
one
off
so
I
don't
break
anything
I'm
not
to
in
regard
I'm.
Gonna,
save
that
so
now
to
do
the
demo
correctly.
Let's
just
do
another
one
right
just
for
the
essence
of
time.
I'm
gonna
build
another
one
and
then
you'll
see,
because
now
that
I
have
the
policy
actually
set
right,
you'll
see
when
it
gets
to
a
point
where.
B
So
what
did
I
build?
So
that's
what
I
built
seven?
Yes!
So
then,
off
that
per
to
perspective
now
we're
gonna
go
through
an
hour
should
actually
go
through
when
it
gets
to
that
point,
we'll
see
that
actually
restricted
from
a
policy
perspective
so
now
kind
of
walking
back
through,
while
that's
cooking,
essentially
what
we've
done.
What
we
have
here
is
that
obviously,
looking
across
all
your
pods,
we
can
see
the
pods
on
here
see
the
state
of
the
pod.
The
last
commands
that
will
reign
across
that
pod.
B
Here's
the
first
and
then
I
kind
of
did
from
that
regard.
I
can
pull
up.
You
know
some
compliance
and
info.
Obviously
this
containers
running
you
know
as
route.
You
know
app
armors,
not
configured
set
comp
and
Limerick
limit
memory
usage.
You
know
obviously
I
checked
five.
Ten
in
that
particular
regard.
I
can
see
the
host
apology,
here's
you
know
so
from
our
perspective,
we're
not
really
a
host
layer
protection
product,
but
essentially
we're
from
the
dr.
Damon
table
right.
So
as
you
have
that
dr.
Damon
you
deploy
OpenShift
on
top
of
that,
dr.
B
Damon,
essentially
we're
protecting
that
up
across
that
particular
topology,
and
you
can
see
how
the
state
of
the
host
is
running
from
that
particular
regard.
Think
the
network
card,
think
storage,
because
if
those
get
affected
that
affects
the
containers
on
the
topology
and
then
as
we
kind
of
go
through,
hey
look:
here's
the
daemon,
the
daemon
configure
files,
you
know
set
comp
those
kind
of
things
like
that
notice.
Everything
looks
good
now
we're
kind
of
looking
at
the
images
as
they
exist
across
here's.
You
know
on
the
registry.
B
Here's
doctor
I/o,
you
know
as
they
look
across
and
what
we
bring
in
from
a
product
perspective.
Is
that
hey
look
here,
I'm
now
breaking
down
the
vulnerabilities
right
and
so
actually
go
out
to
the
nvd
database.
You
can
see
the
state
of
that
vulnerability,
but
really
providing
eyes
into
the
environment.
So
here's
that
image
right.
Here's
the
compliance
posture
of
that
image.
Here's
the
process
info,
here's
what
we
detected
as
part
of
that
image.
This
is
going
back
to
that
white
list.
B
I
was
kind
of
talking
about
here's
the
packages
we
kind
of
determined
that
were
part
of
that
you
know
as
we
go
across
you
see.
This
is
a
pretty
big
image
in
that
regard
and
then
really,
as
you
look
across
really
the
CVE
perspective
of
that
particular
package.
That's
in
that
image
as
well.
You
can
see
how
they
light
up
in
that
particular
regard
and
then
kind
of
from
a
configuration
perspective
where
that
image
is
deployed.
You
can
kind
of
see
that
configuration
data.
So
all
across
this
you
can
see
hey
look.
B
This
one
has
29,
so
I
can
go
in
here
and
see
the
vulnerability
state.
You
know
go
out
to
the
nvd
database
and
then
do
that.
So
really,
what
you're
looking
at
is
that
all
you've
done
is
you've
deployed
a
you
through
your
CI
pipeline
process,
whatever
that
might
be
you've
integrated
in
the
registry.
We've
already
added
the
registry
in
here
and
now
you've
dumped
that
image
in
the
registry.
We're
gonna
automatically
assess
the
state
of
those
images
that
sit
in
that
registry
right.
A
It's
it's,
it's
really
cool
and
it's
you
know
it's
interesting
to
see
the
vulnerabilities
in
there
in
some
of
the
Oakland
ship
containers
too,
and
hopefully,
three-point-three
is
better
I.
Don't
I've
did
a
lot
of
work
a
while
back
with
compliance
and
audit
reporting
and
scanning.
For
that
you
have
any
output
me
I,
see
CSV,
but
like
I'll,
be
like
a
vulnerability
report.
A
B
So
how
we
do
so
right
now
in
the
product
we
are
going
through
we're
starting
a
UI
remap,
so
some
stuff
will
come
out.
Are
we
ever
really
finalized
a
plan
in
that
particular
regard,
but
really
these
this
way
to
answer
the
question:
is
that
essentially
throughout
the
product,
if
you
need
to
export
anything
out,
we
really
give
you
the
ability
to
do
a
CSV
export,
so
you
obviously
can
filter.
So
you
get
very
specific
information.
B
B
So
we've
actually
so
when
you
look
at
it
right,
so
we
looked
at
you
know
when
we
sat
down
and
we
thought
about
this
product
right.
Essentially,
we
looked
at
you
know:
where
does
it
fit
in
the
in
the
market?
Right
so
obviously,
there's
a
lot
of
good
products
already
out
there
that
do
hardware
based
assessment.
Those
kind
of
things
like
that
you
know
think
cloud
cloud
passage
tripwire
those
kind
of
things
like
that,
as
we
kind
of
go
through
and
then
we
already
have.
B
We
have
a
great
partnership
with
a
company
called
Sano
type
who
does
licensing
the
integration
as
well
right
from
a
took
the
regard,
so
we
said:
okay,
well,
hey
look,
you
know,
Sano
type,
obviously
does
deep
in
the
licensing,
so
we
kind
of
said
we're.
Gonna
stay
in
our
niche
from
that
trigger
perspective,.
A
B
Yeah,
so
so
really
the
easiest
way
to
answer
that
is
that
so
Sano
type
is
one
of
our
partners
and
they
do
have
that
capability
and
we've
actually
integrated.
We
were
finalizing
the
engineering
of
integrating
our
products
together
right
and
so,
if
you
or
a
sauna
type
based
customer,
that
would
be
one
thing
you
could
get,
because
obviously
they
have
the
licensing
the
job
of
a
specific
information.
We
have
all
the
containerized
ecosystem
and
really
think
of
bridging
those
two
capabilities
together
from
a
product
perspective,
to
really
help
answer
that
question.
B
Go
back
and
see
where
it's
at
and
see
if
we
actually
got
that
restriction
right,
and
so
obviously
I
demoed
this
all
morning
and
it
was
working
part
narratives.
So
now
you
can
kind
of
see.
Hey
look
air
sinking,
pod
skip
fail
to
create
running
containers
because
it's
got
basically
basically
policy
blocked
it
right.
So
now,
essentially
it
is
in
a
basically
a
looping
state,
so
OpenShift
is
basically
trying
to
make
that
OC
call
to
kick
it
and
every
some
time
that
call
comes
through
our
integration
from
the
socket
we're
blocking
that
right.
B
So
simply
enough,
I
could
go
into
here.
Don't
want
to
trust.
You
know,
show
kind
of
the
flexibility
of
it
right
going
to
compliance.
Go
into
this
policy
check
my
set
and
go
into
five
ten
on
that
particular
regard
and
then
set
that
back
to
alert,
save
that
off
and
then,
when
I
go
back
into
here,
I'm
essentially
you'll
see
that
deployment
kicks
off
right
and
from
that
to
the
regard,
and
then
open
ship
will
go
off
and
then
that
that's
running
in
that
regard.
A
B
It's
kind
of
what
we're
talking
about
is
that
so
one
of
the
things
that
we're
working
on
from
a
product
perspective
is
actually
bringing
that
to
fruition
right.
So
so,
actually
having
some
exposure
in
the
UI
I
know,
my
CTO
just
had
a
meeting
with
Red
Hat.
So
those
those
conversations
are
going
on
as
we
speak
and
we
are
working
through
that
right.
So
all
the
different
vendors
were
working
to
make
sure
that
it's
it's
the
most
seamless
experience
as
possible,
and
so
that's
one
of
the
things
that
we
have
to
do
right.
B
A
B
B
This
is
kind
of
what's
happening
on
the
back
end
through
the
daemon
right,
and
this
is
kind
of
what
you're
seeing
in
that
particular
regard
as
things
kind
of
go
through
and
that
would
get
exposed
back
in
the
UI
in
that
particular
regard
that
deployment
failed,
whatever
it
is,
and
when
they,
you
know,
look
in
the
logs.
That's
the
kind
of
permissions
are
gonna,
see
on
the
back
end
right.
So
look
at
really
kind
of
what
I
showed
here
is
the
backend
integration
and
then
what
we
need
to
build
is
that
front-end
experience
don't.
A
A
B
You
yeah,
so
what
I
should
do
is
maybe
we'll
follow
up
with
you.
Diane
is,
as
we
get
you
know
further
down
from
an
engineering
cycle
perspective.
In
that
regard
you
know
we
could
you
know
that's
what
the
idea
is
we'll
schedule,
another
call
and
show
where
we've
you
know
now,
six
months
later,
here's
where
we're
at
as
an
example.
A
That
would
be
a
great
thing
to
do
so.
I
see,
you've
done
a
really
good
job
and
been
very
thorough
because
there
haven't
been
it
really
too
many
questions
here,
though,
is
I'm.
Gonna,
give
everybody
a
last
chance,
and
maybe
if
you
go
back
your
slides
and
put
up
your
informational
sides
so
jump
on
the
holding
these,
you
have
questions
well
kind
of
wrap.
This
up
a
little
bit
go
because
we
are
almost
at
the
end
of
our
hour.
A
If
anyone
has
any
questions
pop
them
into
the
chat
or
raise
your
hand
and
I'll
unmute
you
but
I
I
think
you've
done
a
very
awesome
job
covering
office,
and
hopefully
there
will
be
no
flaming
containers
out
there
afterwards
and
we'll
post
this
video
in
the
blog
post
at
blog,
fed
Oprah
com
shortly.
Let
me
take
this
a
day
or
two
to
get
them
cycled
through
and
read
all
them
all
available
and
ready
for
you
on
our
youtube
channel
as
well.