►
Description
OpenShift provides a dynamic, scalable, secure environment to host applications, whether you’re modernizing legacy apps or operating with full DevOps methodologies. When it comes to running containers, there are additional steps you should take to maximize the security of what happens within them.
Join Tsvi Korren, Field CTO at Aqua Security, as we discuss:
The complexities of cloud native application security when deploying in OpenShift environments,
Best practices for securing applications, containers, VMs, and functions on OpenShift
Enhancing node security on OpenShift
Maximizing security at runtime and protecting against unpatched vulnerabilities
A
And
we're
rolling,
we
are
live
streaming
on
the
internet
today,
I'm
michael
wait.
This
is
the
open
shift.
Commons
briefings
this
is
our
operator
hours
show,
and
today
we
have
with
us
aqua
security
and
not
just
anyone
from
aqua
security,
but
we've
got
sv
karen,
who
is
their
field
cto
from
aqua
joining
us
in
our
very
own
dave
muir
who's?
An
essay
focused
around
our
top
tier
software
partners,
how's
it
going
fellas.
B
A
Yes,
yes,
welcome
to
the
show.
We've
got
one
fun-filled
hour
here
today:
we're
we're
streaming
live
on
twitch,
we
are
on
youtube
and
we
are
on
facebook,
and
people
will
be
able
to
be
asking
questions
on
those
shows
on
those
those
channels
as
usual,
and
any
questions
that
come
in
we'll
be
able
to
address
them
down
here
in
the
in
the
chat
sv,
you
are
the
field
cto
at
aqua.
What
is
what
does
that
entail.
B
So
it's
a
it's
a
pretty
new
role
in
the
industry
in
general,
but
the
way
that
I
like
to
think
about
it
is
that
if
I
was
the
cto
of
any
of
our
customers,
what
would
I
do
to
make
containerization
cloud
native
security
to
be
the
best
that
it
can
be
for
that
customer?
So
it's
a
pretty
encompassing
role.
You
know
it
goes
product
process,
customers
and
it's
pretty
exciting.
I've
been
doing
it
for
about
a
couple
of
years
now.
A
B
Yes,
so
I
joined
shortly
after
the
company
was
established.
I
was
actually
the
first
employee
in
north
america.
The
company
is
based
out
of
israel
and
yeah,
so
I
started
doing
basically
everything
just
walking
with
our
ceo
and
field
cto,
just
as
the
three
man
crew
going
into
potential
customers
in
new
york
city,
knocking
on
doors,
doing
everything
you
need
to
do
in
a
startup
environment
and
then
kind
of
grow
with
the
industry.
A
Yeah
that
that's
pretty
that's
pretty
interesting,
so
you've
been
there
from.
Basically,
you
know
close
to
inception
until
you
know
now
where
aqua
is
a
is
a
household
word
and
a
pretty
mainstream
security
vendor
in
in
computing?
What's
changed
during
the
time
that
you've
been
there
and
and
I'll?
Just
give
you
an
example
of
why
I'm
asking
like
when
I
started
at
red
hat
it
was
in
2002
and
I
was
a
solutions
architect
dealing
with
customers,
and
you
know
when
we
would
go
in
and
I'd
be
supporting.
You
know
our
my
account
executives.
A
We
spent
most
of
our
time
as
opposed
to
trying
to
sell
red
hat
product
trying
to
sell
open
source
and
convincing
customers
that
open
source
was
good
and
that
it
wasn't
just
you
know,
people
with
blue
hair
and
skateboards,
and
it
was
really
challenging
to
be
able
to
have
just
you
know,
sell
open
source
convince
people
of
why
you
know
a
paid
offering
is
good.
You
know
you
fast
forward
to
today,
and
we
don't
have
that
challenge
anymore
of
trying
to
convince
people
that
open
source
is
good.
A
B
B
You
know
bridge
that
gap
between
devops
as
such
as
it
was,
and
security
telling
people
why
they
need
to
think
about
security,
specific
for
these
environments,
and
then
you
know
once
the
industry
took
off,
it
became
really
how
to
bring
security
into
all
that
that
extreme
series
of
innovations
that
happened
all
the
way
from
developing
containerization
on
mass,
connecting
it
to
cloud
environments,
kubernetes
became
a
thing.
Of
course.
Openshift
became
a
thing
and
it
was.
It
was
really
accompanying
the
entire
growth
of
the
industry.
A
A
Customers
can
have
the
confidence
of
deploying
your
products,
along
with
our
products
in
a
production
environment
and
feel
have
that
that
reese's
peanut
butter
cup
moment
of
the
peanut
butter
and
the
chocolate
have
come
together,
and
you
know
they
can
get
the
support
they
need
in
a
production
environment.
Are
you
folks,
in
the
red
hat
marketplace
as
well,
operated
by
ibm.
A
C
Yeah,
as
you
know,
we
have
a
lot
of
focus
on
our
partners.
There's
a
lot
of
technical
folks,
a
lot
of
sellers
that
deal
with
partners
at
red
hat,
which
is
great,
I'm
specifically
focused
on
our
security
isvs
globally
and
especially
around
the
function
to
get
them
to
market.
So
I
help
our
our
security
partners
understand
how
to
get
certified,
how
you
know
get
them
in
front
of
the
right
people
in
red
hat
to
complete
that
certification.
C
B
A
C
Well
sure
yeah,
so
what
I
wanted
to
first
talk
about
is
one
of
the
major
items
we're
doing
this
year
as
part
of
my
team,
part
of
the
security
team
and
I've
been
working
with
a
lot
of
folks
at
red
hat
internally
across
teams
and
who,
who
are,
are
focused
on
security
to
have
they
sort
of
come
up
with
a
devsecops,
unified
vision
across
the
company.
One
of
the
things
we're
doing
around
that
is
producing
a
series,
a
monthly
series
of
security
topics.
C
C
So
every
month
we're
gonna
push
out
three
podcasts,
those
have
been
for
march.
Those
have
been
already
dropped
and
then
two
openshift
tv
shows
this
is
the
second
one
we've
done
in
march
and
the
first
one
was
a
couple
couple
weeks
ago
as
well.
That
series,
the
the
one
we
did
a
couple
weeks
ago
is
called
devsecops
is
the
way
we're
really
excited
to
bring
you
all
this
content.
C
So
that's
the
plan
every
month
and
since
march
is
vulnerability
month.
This
is
the
last
day
of
march.
I
did
want
to
talk
about
the
certification
that
we
released
about
a
month
ago.
It's
called
the
red
hat,
vulnerability,
scanner,
certification
and
the
reason
why
we
created
it
is
probably
shown
in
this
picture
in
the
middle
here.
C
Where
we
can
say
you
know,
this
partner
has
met
the
requirements
of
the
container
scanning
certification,
and
so,
when
you
get
a
report,
you'll
see
a
lot
less
discrepancies
between
what
red
hat
says
and
our
our
partner
scanner
report
says
and,
and
it
was
it
was
not
an
easy
process
for
both
red
hat
and
our
partners
a
lot
of
times.
Our
partners
had
to
modify
their
code
and,
and
the
key
requirement
was
to
a
couple
key
requirements.
C
One
was
to
make
sure
that
red
hat's
providing
the
right
feed
to
our
partners
and
they're
consuming
the
right
feed,
which
is
our
oval
version
two
feet,
and
then
another
requirement
was
to
try
to
add
information
to
our
partners
scanners
that
shows
red
hat
severity
and
red
hat
links.
So
when
you
get
that
report,
you'll
see
well,
here's
what
you
know
aqua
says
about
this
vulnerability
and
maybe
side
by
side.
Here's
what
red
hat
says
about
this
vulnerability
as
well,
and
you
can
click
to
go,
see
more
information.
C
C
C
I
wanted
to
jump
also
now
so
that's
vulnerability.
Information
and
this
slide
here
talks
to
some
of
the
categorization
I
was
talking
about
earlier
and
how
we
framed.
You
know
this
year
with
our
monthly
security
topics,
so
I
mentioned
the
nine
car,
the
nine
categories
and
the
34
security
methods.
Previously,
this
is
what
it
would
look
like.
So
what
we
were
able
to
do
after
determining
those
categories
is
to
map
the
integration
spots
onto
a
devops
pipeline.
C
C
So
as
you're
going
through
each
piece,
you
can
look,
for
example,
at
build
automation.
You
can
say
yourself!
Well
am
I
doing
some
sca
or
software
composition,
analysis,
understanding!
Your
dependency
in
build
am
I
looking
at
network
policies.
If
not,
maybe
I
should
look
at
aqua
to
do
those
things,
so
this
has
really
been
a
helpful
guide
for
our
for
our
partners
as
we
as
we
go
through,
you
know
the
journey
to
help
them
get
to
to
to
devops.
C
Ultimately,
we
like
to
call
it
devsecops,
I
know
they're
the
same
thing:
there's
there's
a
there's.
A
little
bit
of
a
debate
around
that
devops
in
its
beginning
has
always
had
security
in
mind,
but
just
calling
out
that
security
word
that
sec
word
really
helps
to
make
the
point
that
security
does
need
to
be.
Automated
does
need
to
be
baked
in
from
the
beginning
in
your
journey.
C
So
from
a
slides
perspective,
I
think
I'm
going
to
stop
sharing
here
and
you
know
one
thing
I
wanted
to
mention
and
see
I'll
bring
you
into
this
conversation
as
well.
Is
we've
been
talking
this
month
about
vulnerability,
analysis
scanning
third-party
dependencies,
but
there
are
a
lot
of
complexities
around
that
it's
just
not
as
easy
as
that.
Diagram,
right
and
vulnerabilities
is
part
of
part
of
looking
at
risk
management.
C
B
Yeah
definitely
so
I
I
think
one
thing
to
remember
is
that
when
we
talk
about
vulnerability
management
in
a
lot
of
people's
heads,
this
is
around
vulnerabilities
in
images
and
vulnerabilities
and
images
are
a
result
of
the
fact
that
we're
using
a
lot
of
open
source
components
and
those
open
source
components,
of
course,
have
software
bugs
that
some
sometimes
have
security
implications.
And
we
need
to
manage
that
risk.
B
B
And
I
think,
as
you
go
through
your
your
your
series
as
we
go
throughout
the
year,
I
think
we're
building
on
that
right.
So
we're
going
to
talk
about
vulnerabilities
today
and
how
we
can
read
out
the
risk
in
images.
But
it's
important
to
understand
that
vulnerabilities
are
not
the
end-all
be-all
of
a
security
program
and
we
need
to
pay
attention
to
the
other
parts
as
well.
C
Yeah,
that's
why
I
think
this
this
session
today
is
such
a
good
segue,
and
it's
a
good
reminder
for
folks
that
you're
right
vulnerability
analysis
is
great
and
you
should
have
it.
But
it's
not
it's
not
everything
right!
It's
to
get
a
comprehensive
security
solution.
You
gotta
you
have
to
look
at
other
vulnerability
points
and
things
like
that,
because
there's
there's
a
lot
of
these
different
attack
vectors
right.
If
you
could
talk
a
little
bit
more
about
those
attack,
vectors
and
and
how
they
play
a
role
in
this
as
well.
B
Yeah,
so
so,
even
if
you
take
the
vulnerabilities
in
in
images,
we
got
to
remember
that
the
vulnerabilities
are
images
are
potential
risk
right,
an
image
is
not
a
live
thing.
It's
inert
and
let
me
if
I
can
I'll
just
go
ahead
and
share
my
screen
here
and
I'll.
Show
you
some
of
the
analysis
that
we're
doing
with
regards
to
to
what
is
the
vulnerability
vulnerabilities
in
image.
So
this
is
this
is
how
aqua
looks
at
the
list
of
images
and
here's
an
an
image
here.
B
You
know
it
has
a
couple
of
you
know
one
critical
vulnerability.
You
know
one
high
one
low.
If
we
click
on
that
image
and
get
the
list
of
the
components
that
that
are
vulnerable,
you
know
we
can
see
that
there
are,
you
know
a
few
of
them.
This
is
alpine
based,
so
you
can
see
that
there
are
some
components
there.
You
know
we
can.
B
We
can
look
at
that
vulnerability
and
we
can
see
how
the
the
nvd
regards
it
and
so
on,
but
but
I
think
in
a
lot
of
organizations,
especially
because
there
is
a
vendor
fix
for
that
image
right,
you
can
update
the
image.
A
lot
of
organizations
are
going
to
let
that
image
pass
at
least
the
initial
or
at
least
give
it
a
grace
period
in
order
to
be
to
be
used
in
the
environment.
B
B
As
as
you
run
it,
we
are
seeing
some
really
really
weird
behaviors
we're
seeing
that
you
know
it
opens
network
connections,
it
opens
ssh
connections,
it
downloads
files
and
and
all
those
behaviors
actually
resulted
in
a
a
cryptocurrency
miner
being
instantiated
with
the
result
address
going
to
the
country
of
iran.
So
those
are,
you
know
no
disrespect
to
iran
or
anybody
else,
but
the
idea
is
that
that
we
need
to
kind
of
understand
what
is
the
difference
between
our
potential
risk
and
what
is
the
real
risk
in
the
the
image?
C
Yeah,
I'm
wondering
so
because
this
topic
about
vulnerabilities
and
really
around
dependencies
has
has
been
out
in
the
industry
now
for
a
while.
Do
you
see
sort
of
out
in
the
field
more
companies
getting
a
better
handle
on
scanning
for
their
dependencies
earlier,
and
then
I
guess
second
part
to
that
question.
Is
you
know
what
what
do
you
see
in
terms
of
when
you
go
into
companies
the
biggest
gap
that
they
have
in
terms
of
detecting
vulnerabilities
across
across
the
life
cycle?
That
makes
sense.
B
Yeah,
I
I
think
the
the
the
the
adage
of
shift
left
basically
putting
our
vulnerability
management
and
risk
reduction
program
as
early
as
possible
in
the
development
life
cycle
is,
is
a
really
good
thing.
On
the
other
hand,
we
need
to
make
sure
that
the
people
that
are
absorbing
that
information
really
know
what
what
to
do
with
it.
B
So
if
we,
if
we
take,
for
instance,
an
image,
that's
like
this,
this
middle
image
here
you
know
it
has-
you
know
quite
a
few
vulnerabilities
and
we
can
kind
of
take
a
look
at
the
the
list
of
them,
and
you
know
we
have
the
the
rating
of
that
vulnerability
and
and
and
and
and
you
get
I
don't
know-
20
30
40-
maybe
even
a
few
hundred.
If
it's
a
really
really
old
image,
and
then
the
question
is
what
do
you
actually
do
about
it?
B
So
if
I'm
a
developer
or
a
software
packager
or
a
devops
person,
and
I
get
that
list
of
vulnerabilities
the
question
I
have
is
okay:
what
can
I
do
about
it
as
you
can?
You
can
see
aqua
kind
of
provides
a
few
low
hanging
fruits
right?
So
all
of
these
have
vendor
fixes
right.
So
if
you
open
the
vulnerability
card,
this
happens
to
be
a
red
head
vulnerability
and
that
that's
a
particularly
old
image.
B
We
can
see
that
you
know
the
scoring
that
we
get
is
is
from
the
cvs,
but
we
also
get
the
the
red
hat
score,
which
is
actually
in
this
case
actually
in
line
with
with
the
one
with
the
the
vulnerability,
but
it
doesn't
have
to
be,
and
then
you
know
what
is
the
the
recommendation
so
first
try
to
update
the
package
to
a
newer
version,
and
then,
if
you
can't
you
know,
can
we
do
some
mitigation?
You
know
using
runtime
policies.
B
Can
we
do
an
acknowledgement,
maybe
work
with
our
security
organization
to
see
if
there
are
any
other
factors
that
can
compensate
for
that.
However,
I'll
point
you
into
these
two,
these
two,
it's
kind
of
small
here
but
but
an
exploit
is
not
available.
So
basically,
this
vulnerability
doesn't
have
an
exploit
in
the
wild.
Nobody
has
published
a
script,
an
executable
that
can
take
advantage
of
that
vulnerability,
and
also
you
don't
have
any
workloads
running
right.
B
So
we're
scanning
the
images
from
the
registry
or
we're
scanning
the
images
as
they're
being
produced
in
in
the
pipeline,
but
we
haven't,
we
don't
have
any
in
this
case.
We
don't
have
any
images
that
are
running
or
we
don't
have
any
containers
that
are
running
in
openshift
from
from
this
image.
So
the
question
is:
how
can
we
prioritize
that
right?
What
what
is?
What
are
all
the
data
points
that
we
can
have
in
order
to
not
be
hit
with
a
list
of
100?
B
One
of
the
things
that
that
we
can
make
sure
that
are
are
the
the
best
thing
that
that
we
can
fix
that
are
gonna,
give
us
the
best
bang
for
the
buck,
and-
and
in
that
case,
what
what
aqua
came
up
with
is
something
that
we
call
the
risk-based
insights,
and
that
is
if
we
take
the
entire
vulnerability
inventory
in
our
environment.
You
can
see
that
we
have
this
slider
on
top.
C
B
Of
the
repositories
like
red,
hat
or
or
other
distributions
are
maybe
reducing
the
the
score
of
the
vulnerability
versus
the
nvd.
We
only
need
to
show
the
things
that
are
really
really
important
per
the
distribution,
and
then
we
want
to
understand
if
there
are
things
that
can
be
exploited
from
the
network,
because
remember
nvd
is
a
general
program.
It
precedes
containers
right.
So
it's
a
general
purpose,
vm
vulnerability
repository.
B
So
not
everything
that
you
can
you
see
on
the
nvd
as
a
high
or
critical
is
something
that
can
be
exploited
in
a
well-managed
containerized
environment.
So
if
you
need
to
be
on
the
on
the
operating
system
itself,
with
command
line
access
with
even
root
access
in
order
to
exploit
that
vulnerability-
and
it
can
be
just
directly
exploited
from
the
network-
it
doesn't
mean
that
we
need
to
ignore
it.
B
We
need
to
make
sure
that
the
the
owners
of
those
images,
the
owners
of
the
the
software
have
an
understanding
of
what
their
software
is
built
from,
but
also
we
can't
expect
them
to
fix
a
hundred
percent
of
the
vulnerability.
So
we
need
to
give
them
some
idea
as
to
what
are
the
things
that
they
need
to
concentrate
on
first
and
then
work.
C
C
C
B
Yeah,
that's
true
and
that
the
process
is
is
what's
critical
here,
yeah,
you
know
we
there
needs
to
be
some
good
intention
on
both
sides
right.
We,
we
can't
expect
the
development
side
to
fix
100
of
the
vulnerabilities,
on
the
other
hand,
having
security,
putting
a
rule
that
says
that
you
will
not
have
any
critical
vulnerability
in
any
of
your
containers
whatsoever
is
also
probably
not
feasible,
because
a
lot
of
them
you
don't
do
not
have
a
fix
and,
and
then
you
you're
stuck.
B
B
So,
for
instance,
if
if
we
take
a
look
at
the
infrastructure
right,
the
hosts
and-
and
this
is
this-
is
my
my
openshift
environment
and-
and
we
take
a
look
at-
let's
see
the
ones
that
I'm
managing.
You
can
see
that
that
these
two
hosts,
which
are
the
the
optimized
operating
system
for
for
openshift,
really
don't
have
a
lot
of
vulnerabilities
in
them.
B
Actually,
there
are
not
no
detected
vulnerabilities
in
them
and
that's
because
we
we've
taken
our
our
openshift
environment,
our
docker
environment
and
deployed
them
on
a
hardened
operating
system.
That
has
very
few
components
that
the
containerized
environment
do
not
need,
and
that
allows
us
to
then
maybe
not
mind
as
much.
If
we
have
some
of
those
vulnerabilities
that
cannot
be
exploited
remotely
because
you
really
can't
access
the
host.
B
Good
understanding
understand
what
the
risk
posture
overall
and
not
just
hang
their
hat
on
the
vulnerability
management
of
images
and
try
to
kind
of
pin
all
their
security
problems
on
that.
Because
you
know
this
goes
one
much
wider
than
that
all
the
way
into
the
runtime
environment,
of
where
those
containers
will
will
eventually
run.
C
B
So
if
you
think
about
the
the
life
cycle
of
the
image
right,
you
you
want
to
first
of
all
test
your
base
images.
So
if
you
are
building
on
base
images,
you
want
to
make
sure
that
you're
not
introducing
risk
just
by
having
that
base
image
and
aqua
can
actually
resolve
that
and
we
can
show
you
when
vulnerabilities
are
coming
from
if
it's
coming
from
the
base
layers
of
the
the
upstream
layers.
The
other
thing
is
that
we
we
need
to
test
in
various
places.
B
B
So
I
can
build
my
images
on
on
top
of
that
and
if
I,
then
we
decide
that
we
need
to
move
to
red
hat
eight,
then
I'm
not
taking
it
directly
from
the
repository
I'm
taking
it
from
that
curated
registry,
where
the
organization
has
already
tested
it
and
has
blessed
that
image
and
makes
that
available.
So,
first
of
all,
getting
a
handle
on
the
base.
Images
is
something
that
we
absolutely
recommend
and
have
been
recommended
for
for
the
past
five
years.
The
other
thing
is
once
that
image
is
produced.
B
We
want
to
let
people
understand
as
soon
as
possible.
What
are
the
potential
issues
in
that
one
in
that
image,
so
integrating
with
the
development
environments
with
the
build
environment,
integrating
with
the
ci
tool
aqua,
has
a
command
line
scanner
that
can
be
employed
anywhere
inside
of
the
ci.
You
don't
have
to
use
the
aqua
ui
to
do
it.
It's
integrated,
that's
that's
the
the
version
that's
been
certified
with
with
red
hat
and
and
then
once
an
image
gets
to
the
registry.
B
It's
also
important
to
understand
that
the
vulnerability
posture
might
change
over
time,
because
vulnerabilities
are
discovered
on
existing
components.
So
just
because
we
scanned
the
base
image
and
gotten
a
snapshot
in
time,
and
then
we
scanned
our
artifact
and
gotten
a
snapshot
in
time
doesn't
mean
that
our
job
is
done,
because
we
also
need
to
understand
for
the
life
cycle
of
that
image.
Whether
or
not
new
vulnerabilities
have
been
discovered
on
the
components
that
are
that
are
already
in
the
image.
B
C
Cool
and
actually
we
have
a
question
that
came
in
so
I
think
it's
relevant
to
what
we
just
talked
about,
but
while
it
is
asking,
can
I
verify
the
image
in
a
host?
Was
the
canonical
image
pulled
from
a
trusted
registry?
Not
tampered
with?
This
did
not
happen
in
cluster
d
scenario.
Last
couple
of
weeks.
B
Yeah,
so
one
of
the
things
that
that
we
do
with
aqua
is
that
we
as
we
as
we
scan
an
image.
We
also
take
the
metadata
of
the
image
and
including
calculating
a
hash
of
that
image,
is
being
started
by
its
authenticity
as
you
roll
it
out
and,
and
one
of
the
things
that
that
organizations
I
think
are
just
starting
to
figure
out.
B
Is
that
just
because
somebody
pushed
an
image
to
the
registry
written
the
the
implementation
of
registry
back
from
the
darker
days
ever
since
they
kind
of
start
working,
which
is
another.
You
know
vestige
of
of
practice
that
we
probably
want
to
get
rid
of.
We
really
don't
want
to
use
a
common
tag
for
different
images.
We
want
to
use
unique
tags
for
images
in
the
same
repository,
and
we
want
to
make
sure
that
that
there
is
a
binary,
hashable,
verifiable.
B
Match
between
what
we
developed,
what
we
put
in
the
registry
and
it
eventually
what
we,
what
what
what
we
deployed,
because,
yes,
a
registry
will
will,
if
you,
if
you
can
authenticate
to
it,
will
will
happily
accept.
You
know
to
override
an
image
and
a
and
a
kubernetes
based
environment
is
also
going
to
happily
accept
almost
any
image
from
a
a
registry
that
it
can
access
and
it
can
authenticate
to.
C
B
Yeah,
I
think
image
acceptance,
I
think
is,
is
a
really
really
important
pillar
in
in
our
risk
management
program.
As
I
said,
a
kubernetes
cluster
will
happily
accept
any
image
of
a
registry
that
it
can
connect
to
and
there's
a
few
problems
with
that.
First
of
all,
nobody
deletes
old
images
from
the
registries
and
and
the
image
streams.
B
So
so,
there's
always
the
potential
of
by
mistake
you,
you
will
use
an
older
image
that
have
a
vulnerability
posture
that
you
don't
want,
or
even
you
know,
the
software
is
going
to
be
out
of
the
that
you're
trying
to
roll
out
so
so
the
question
is:
how
do
we
manage
that?
Everything
that
we're
going
to
roll
out
is
going
to
be
the
most
current
and
the
most
secure?
The
appropriate
thing
that
that
we
want
to
to
deploy
an
admissions
controller
are
the
the
tool
they
actually
you
know
that's
what
they
are.
B
They
they
would
control
which
images
are
admitted
to
the
the
environment.
So
you
know
in
the
aqua
environment,
if
you
deploy
aqua
on
your
cluster,
something
to
be
called
the
kubernetes
based
enforcer,
you
will
get
an
admissions
controller
that
can
verify
the
security
status
of
of
images
and
each
image
that
is
being
scanned
by
aqua
based
on
policies
that
define
the
risk.
B
On
the
flip
side,
you
also
have
a
big
chunk
of
images
that
may
not
be
known
to
your
security
environment,
and
another
thing
that
you
can
do
with
aqua
is
to
to
not
allow
unregistered
or
basically
unfamiliar
images.
So
when
we
talk
about
the
acceptance
gate,
we
ask
ourselves
three
questions:
is
it
something
that
we
know
about?
Is
it
something
that
we
expect?
Is
it
like
the
right
time
to
deploy
an
image,
and
then
what
is
the
risk?
Tolerance
that
we
have
for
that
particular
deployment?
B
And
we
need
to
have
that
flexibility,
because
a
an
nginx
that
is
being
deployed
as
an
internal
component
to
a
very
internal
application
might
have
different
security
needs
than
an
nginx
that
is
deployed
as
a
front
end.
So
all
of
these
decisions
are
kind
of
culminating
in
that
admissions
controller,
which
you
need
to
have
a
decision
tree
of.
Is
that
image
expected
do
I
do
do.
I
know
that
I've
seen
it
before?
Is
it
coming
from
my
organization
or
somebody
else?
Is
it
something
that
we
expect?
Is
that
the
appropriate
time
is
it?
B
C
Great
it
looks
like
wallet,
has
a
follow-up
question
so
see?
If
I
want,
I
want
to
pull
from
specific
repos
like
from
quay.io.
Currently
he
needs
a.
He
needs.
A
custom,
validating
emission
controller,
can
aqua,
validate
specific
repos
like
paul
from
quay
dot,
io
openshift,
but
reject
from
quay
dot,
io
bad
actor.
B
Yeah,
so
as
part
of
the
controls,
part
of
the
decision,
tree
of
the
admission
controller
is,
is
which
logical
registries
we
want
that
image
to
to
come
from.
So
the
way
that
you
do
it
in
aqua,
you
will
define
your
registry
as
a
logical
registry.
You'll
give
it
a
name.
It
can
have
various
ip
addresses.
It
can
have
maybe
even
a
load
balancer
that
points
to
different
physical
registries.
B
But
as
long
as
that's
that
logical
registry,
that
you
want
to
pull
from,
you
can
basically
put
a
rule
in
aqua
that
says
well
for
this
environment,
even
even
on
a
namespace
level.
For
this
namespace.
I
only
want
to
accept
images
that
come
from
this
logical
registry
that
I
predefined
and
you
can
add
the
conditions
of-
and
I've
seen
it
before,
and
it
is
compliant
with
the
security
posture
that
I
want
to
have
for
that.
For
the
for.
For
that
namespace
cool.
C
C
Cool
yep,
well,
it
says
thank
you.
I
wanted
to
ask
you
know
in
the
field
because
we
hear
about
vulnerable
third-party
dependencies
all
the
time.
Do
you
see
a
lot
of
a
lot
of
this
scenario
that
we've
been
talking
about,
where
a
bad
actor
manipulates
an
image
or
adds
malware
to
images?
How
often
do
you
see
that
out
in
the
field.
B
Yeah,
so
we
you
know
it's
not
super
common,
but
as
you've
seen
earlier
with
that
image
that
had
that
bitcoin
miner,
this
is
an
image
that
was
actually
on
the
docker
hub.
So
so
somebody
had
put
it
out
there.
It
was
part
of
a
repository
that
did
useful
things
and
we're
seeing
those
from
time
to
time,
and
if
you
look
at
the
press,
you
know
different
research
teams
for
different
companies.
Aqua's
research
team
is
is
following
up
on
that
as
well.
B
You
know
advertising
that
there
are
those
instances
and
and
the
the
the
supply
chain
problems
are,
are
not
limited
to
whole
images
right.
We
had
the
the
you
know,
npm
event
stream
incident
of
a
couple
years
ago
there
was
a
survey
that
was
done.
That
said,
that
you
know
there
is
a
a
significant
amount
of
those.
B
Let's
say:
let's
call
them
not
really
well-governed
repositories
on
github
that
that
might
allow
somebody
to
to
insert
some
malicious
code.
There
was
an
incident
that
just
came
through
my
feed
yesterday
about
about
a
something
in
github.
So
so
all
these
things
are
and
there's
no
there's
no
nvd
for
that
right.
There's
no
registration,
you
know
a
global
list
of
components
and
versions
that
we
know
that
are
going
to
be
dangerous
to
use
because
they
were
they
were
compromised
and
that's
why
the
dynamic
analysis
is
so
important.
B
So
if
you
are
accepting
even
a
base
image
from
an
external
source,
put
it
through
a
dynamic
analysis,
run
it
for
a
little
while
see
what
it
does
make
sure
that
it's
not
going
to
do
anything
bad.
If
you
then
put
components
on
it,
especially
a
new
stream
of
components,
you
know
build
your
image
and
again
do
a
dynamic
analysis
on
it.
Try
to
use
it
for
a
while
in
a
sandbox
trace
what
it's
doing,
make
sure
that
it's
not
doing
anything
bad.
C
B
Yeah,
so
that's
that's
yeah!
So
let
me
let
me
kind
of
go
into
into
that,
and
I
and
I
hope
my
my
network
glitch
hasn't
really
destroyed
my
environment,
but
but
the
idea
is
that
we
have
we
a
lot
of
times.
You
see
it
in
in
sub
components.
So
this
is
this.
Is
my
my
wordpress,
I'm
kind
of
port
forwarding
to
to
my
openshift
environment.
This
little
plug-in
here.
B
The
zenmobile
plug-in
is,
is
a
component
that
has
a
an
exploit
that
can
that
can
cause
a
remote
codex
execution,
and
that
means
that
you,
you
know
if
you,
if
you
deploy
it
inside
of
your
wordpress
environment
right.
This
is
a
component
that
can
be
added
later
to
the
image.
It's
something
that
is
dynamic
in
this
environment
and
it's
not
disclosed
you're,
not
going
to
see
it
on
the
nvd
you're
not
going
to
see
it
because,
because
you
know,
there's
no
vulnerability
feed
for
that.
B
B
That
is
going
to
start
a
again
a
cryptocurrency
miner
into
that
environment
and-
and
if
I,
if
I
do
that,
you
can
see
that
just
by
going
into
that
environment,
you
can
see
that
systemvlf
here
and
you
can
see
that
it's
starting
to
to
get
to
take
a
lot
of
this,
the
cpu
of
that
of
of
that
pod.
So
so
that's
that's
part
of
the
problem
right.
B
So
so,
if
I
go
into
my
my
openshift
environment
and
I
try
to
do
the
same
thing,
what
what
I'll
see
is
that,
as
I
go
into
my
pod,
which
is
hopefully
up
and
running-
and
let's
just
make
sure
that
my
connection
is
good.
So
if
I
go
into
my
pod
and
kind
of
put
the
the
processes
together
and
try
to
do
this
with
my
with
with
this
environment,
there
is
an
aqua
component
that
runs
inside
of
openshift
again
as
part
of
that
operator.
B
That
is
going
to
then
sense
that
this
is
a
file
that
that
was
that
somebody
tried
to
add
into
the
container.
That
was
not
part
of
the
original
image
and
therefore
we're
going
to
deny
its
execution.
So
our
fallback,
even
with
good
vulnerability
management,
is
to
deal
with
how
we
want
to
have
our
containers
running,
monitor
them.
B
Make
sure
that
we
deny
execution
of
anything
that
is
not
part
of
that
container
part
of
that
application
and,
at
the
end
of
the
day,
it's
really
all
about
what
is
appropriate
to
run
for
the
workload
for
the
business
purpose,
that
it's
running
right
and
and
security
professionals,
even
developers,
sometimes
kind
of
forget
that
you
know
we're
developing
software
for
a
reason
right.
A
soft
piece
of
software
needs
to
do
something,
and
if
we
can
discover
if
it's
doing
something
that
it's
not
supposed
to
do,
that
is
going
to
be.
B
Our
fallback
doesn't
mean
that
we
need
to
be.
You
know
completely
blase
about
introducing
vulnerabilities
into
the
environment,
but,
but
it
just
kind
of
kind
of
goes
to
show
you
that
vulnerability
management,
you
know,
will
not
be
able
to
protect
you
against
this
particular
intrusion.
On
the
other
hand,
they
are
mitigating
controls
in
runtime.
That
can
really
do
a
lot
of
good
in
these
kinds
of
environments.
C
Yes,
excellent
demo,
I
know
we
have
about
eight
minutes
left
I'll
close
here
in
a
little
bit
before
I
do.
I
I
just
wanted
to
ask
you:
do
you
have
any
interesting
customer
war
stories?
Obviously
you
don't
have
to
name
names
but,
for
example,
you've
walked
into
a
customer.
They
had
no
security
controls
in
place.
You
ran
aqua.
You
found
all
this
interesting
stuff.
Anything
like
that
that
you
could
share.
B
It
it
happens
almost
every
single
time.
It
almost
happens
every
single
time
where
we
go
into
into
an
environment
and
and
and
either
you
know,
on
the
images
themselves
or
on
the
hosts
or
on
the
kubernetes,
based
environment
or
in
the
cloud
environments.
You
know
you
find
those
those
openings
for
attackers
to
gain
foothold
and-
and
you
know,
coming
from
a
security
background,
it's
it's
an
old
adage
that
that
you
know
security
needs
to
be
perfect.
100
of
the
time.
An
attacker
only
needs
to
be
successful.
Once
and
that's
you
know
the.
B
If
we
sum
up
the
entire
cyber
security
methodology,
that's
that's
it
right.
We
need
to
be
perfect
100
of
the
time.
So
so
I
think
my
my
interesting
war
stories
are
really
not
about
security
findings,
but
around
the
process
right
early
on-
and
I
think
to
this
day
from
time
to
time
when
we
go
into
into
a
a
customer
when
we
used
to
actually
physically
go
into
a
customer
and
sit
in
a
conference
room.
That
would
be
the
first
time
that
security
and
devops
actually
met.
B
So
people
will
be
working
in
different
parts
of
the
building
or
different
parts
of
the
company,
and
it
will
be
the
first
time
that
they
were
sitting
face
to
face
and
really
hashing
out,
because
aqua
deals
with
both
sides
right.
We
did
with
the
development
side
and
we
also
deal
with
the
with
the
the
the
the
cyber
security
side.
And
sometimes
there
are
not.
B
Go
went
to
another
building,
went
through
some
doors
and
then
you
know
we're
introduced
to
the
people
of
the
stock
and
and
you
kind
of
explain
to
them
what
what
we're
doing
and
their
initial
reaction
was.
Well,
we
don't
want
anything
to
do
with
it
right,
we're
so
busy.
We
have
other
things
to
do
and
that
we
really
don't
care
about
this
little
corner,
which
is
the
cloud
native
environment
now
granted.
That
was
a
couple
years
ago,
and
I
think,
as
more
and
more
meaningful
business,
caring
workloads
go
into
openshift
right.
B
There's
a
lot
of
willingness
by
the
development
side
to
really
take
the
vulnerability
posture
seriously
to
do
what
they
need
to
do
in
order
to
fix
it
to
invest
the
time
and
effort
in
order
to
fix
it
and
we're
also
seeing
that
the
the
security
organizations
are
are
becoming
more
reasonable.
You
know
understanding
what
is
the
real
risk
understanding
how
to
deal
with
these
environments.
It's
still
a
it's
still
a
learning,
but
but
I
think
we're
making
good
good
headway
around
that.
A
Yeah,
I
got
a
question
for
you:
what's
next
meaning
like
what
do
you
guys
have
going
on
this
year?
We're
we're.
We
just
started
our
q2.
Actually
our
q2
starts
tomorrow.
You
guys
have
any
events
going
on.
Is
everything
going
to
be
still
be
virtual
for
the
rest
of
this
year?
What
about
what
about
kubecon
in
la
it's
coming
up
in
october?
Do
you
think
we're
going
to
you
think
we're
going
to
be
there
in
person
once
again.
B
I
I
for
one
miss
those
those
conferences,
because
I
think
when
you,
when
you
talk
to
people
when
you,
when
you
got
those
those
off
the
hand,
conversations
in
different
places
waiting
for
the
endless
lines
for
the
food,
those
those
really
are
very
valuable
and-
and
you
know,
as
far
as
what's
next,
I
I
think
I
think
the
the
adoption
of
cloud
native
technologies
is
is
going
to
continue.
There's
no
reason
for
it
to
stop.
I
think
workloads
are
going
to
become
smaller
and
smaller
and
smaller.
A
There's
a
there's,
a
question
that
I
wanted
to
sneak
in
here
about
a
half
an
hour
ago,
but
you
guys
were
clearly
not
letting
me
get
a
word
in
edgewise,
so
that's
great
as
containers
get
smaller
and
smaller
and
smaller,
and
you
know
we
start
to
to
really
see
true
micro
services
pop
up
everywhere
and
service
mesh
becoming
more
and
more
important
for
managing
those.
How
does
that
affect
the
aqua
security
story?
If,
at
all.
B
Yeah,
I
think
I
think
service
mesh
has
kind
of
a
a
dual
role
right
it
it.
It
is
primarily
for
level
of
service
routing
discovery
and
making
sure
that
that
workloads
can
find
one
another.
On
the
other
hand,
as
part
of
the
routing
you
can
also
you
know,
enforce
mutual
tls,
you
can
enforce
authentication.
You
can
even
decide
that
some
workloads
should
not
talk
to
to
other
workloads,
so
we're
seeing
service
mesh
as
both
an
entity
that
needs
to
be
managed,
because
it
is
running
as
open
source
software.
B
You
know
sds
of
the
world
and
so
on,
but
it's
also
something
that
can
be
an
enforcement
point
and
at
aqua
we
really
don't
have
a
problem
kind
of
outsourcing
the
enforcement
point
into
a
mechanism
that
is
already
in
the
way
and
can
execute
the
the
required
controls.
So
I
think
the
the
the
fact
that
service
mesh
is
becoming
more
and
more
viable
as
a
as
a
scalable
solution
is,
is
going
to
introduce
a
lot
of
capabilities
for
us
and.
A
Actually,
actually
wallet,
while
it's
contradicting
me,
he
says
in
data
science,
mldl
containers
are
getting
bigger,
sure
not
gonna,
not
gonna.
Disagree
with
you
anyways
we
are.
We
have
30
seconds
left,
you're
you're
live
on
youtube,
you're,
live
on
facebook.
You
live
on
twitch.
Is
there
anything
that
you
didn't
cover?
That's
going
to
prevent
that
phone
call
coming
from
your
manager
or
your
boss,
saying
I
can't
believe
you
were
on
the
internet
for
an
hour.
Why
didn't
you
say
the
following?
B
I
think
I
think
I
covered
everything
I
would
say
you
know
think
think,
broadly,
you
know
don't
concentrate
just
on
vulnerabilities,
think
cloud,
think,
environment
think
the
workloads
think
holistically
and
ends
to
end.
No,
no
single
control
is
going
to
save
you
from
a
sophisticated
attacker,
but
a
series
of
controls
might
frustrate
them
enough
so
that
they
go
elsewhere.
B
A
Sv,
it's
been
excellent.
Having
you
on
here
this
is.
This
has
been
terrific,
I'm
hoping
that
you
can
come
back
and
and
join
us
again.
We
also
have
a
podcast
series.
It's
called
the
red
hat
x,
podcast
series
it's
on
itunes,
google
play
and
like
41
other
sites
like
spotify,
and
it's
all
over
the
place.
Maybe
you
want
to
do
a
podcast
with
us
here
coming
up
in
the
next
month
or
so.
I
think
I
think
this
is
a
great
topic.
We
could
have
some
fun
with
it
too.
B
A
You
okay
great
well
thanks
for
thanks
for
making
such
an
interesting
an
interesting
hour
here
for
us
on
the
open
shift.
Commons
briefings
the
operator
hours
we
are
signing
off
here,
because
our
my
producer
is
is
is
chatting
me
up
saying
you're
running
over
again
mike
you
gotta
go
so
so
dave,
muir
and
sv.
Thanks
again
for
for
being
here
today
and
godspeed
and
stay
safe
out,
there.