►
From YouTube: OpenShift Commons Briefing #73: Securing Applications on OpenShift and Kubernetes with Aqua
Description
Even in Containers, application security still matters. Running applications in containers means that many processes need to change. And security is no exception. Beyond the security and configuration of the container platform, there are implications to security of the application development, the way it runs, and how it is protected in production.
The very first line in a Docker file: FROM, is where security begins. The choice of the base image, the prerequisite components and the configuration of the image – all impact the security of the eventual container.
Security considerations are necessary when images are pulled and used. Are the images certified to run? Do they pass the risk criteria of the organization? A containerized environment still requires the demonstration of control, for compliance reasons and for the overall security of the application.
And as containers run, there are requirements to monitor their behavior, prevent modifications and protect them from unauthorized actions.
In this session, Aqua’s Tsvi Korren gives an overview of Aqua’s framework for effective application security in a containerized environment. It begins in the development process, progresses as images are built, continues through assurance of image authorization, and protects all running containers.
A
Hello,
everybody
and
welcome
again
to
yet
another
OpenShift
Commons
briefing,
and
this
time
I'm
really
pleased
to
have
aqua
with
us.
They
are
brand
new
members
to
the
OpenShift
Commons
and,
as
I
always
like
to
do,
is
make
new
members
introduce
themselves
and
what
they
do
in
the
ecosystem
of
OpenShift
and
kubernetes,
and
these
guys
and
folks
were
at
the
keuken
event
in
Berlin
and
I
was
pretty
impressed
with
their
offering
and
then
they
joined
up
to
the
Commons,
and
so
I
was
even
more
happy
to
have
them
as
part
of
our
our
community.
A
B
B
What
we,
what
we
sell
and
what
we
support
has
been
around
for
a
year,
has
been
used
in
in
in
multiple
environments,
both
big
and
small
and
and
and
I'm
happy
to
share
some
of
the
the
product
details
with
you
today,
we're
also
very
much
engaged
in
the
community.
So
we
are
an
open,
shipped
community
member.
We
are
a
private
partner
for
open
shipped.
You
can
find
that
information
on
the
part,
a
section
in
OpenShift.
B
So
what
I'd
like
to
do
is
jump
a
little
bit
into
what
what
we're
doing
today,
and
that
is
talk
about
security
for
for
containers
and
it's
a
pretty
big
subject.
Security
for
containers
touches
a
lot
of
things.
The
way
that
container
is
touch
a
lot
of
things,
it's
a
new
paradigm
in
IT
and
and
it
turns
things
a
little
bit
on
their
head,
the
the
security
that
we've
had
so
far
around
application
development,
the
operations
of
application
deployment
and
the
network's
really
didn't
have
a
lot
of
interface.
Points
and
I
show
up.
B
I
show
a
few
of
the
interface
points,
firewalls
and
and
and
Web
Application
Firewall,
specifically
our
interfacing
between
the
needs
of
the
application,
the
needs
of
the
network,
the
the
way
that
code
is
assessed
and
analyzed
so
out.
The
environment
is
interfacing
with
developers
and
operations
and,
of
course,
there's
the
networking
and
operations
for
server,
config
and
patches
and
containers
right
sit
in
the
middle
of
it.
There's
a
lot
of
capabilities
in
containers.
B
Sometimes
very
disparate
security
practices
requires
attention
and-
and
it
has
been
a
barrier
to
adoption,
because
it
does
turn
the
security
processes
from
being
very,
very
much
late
in
the
security
process
in
the
development
process
into
something
that
needs
to
be
sought
in
advance,
and
this
needs
to
be
a
lot
of
collaboration
between
development,
ops
and
then
security.
So
this
is
where
we
fit
today.
Containers
are
changing
a
lot
of
the
security
process
and
IT
process
in
general,
and
we
need
to
make
sure
that
we
we
follow
up
with
them.
B
Platform
security
and
we're
open
shift
comes
in
is
to
provide
the
best
secure
platform
for
running
containers
from
an
operational
point
of
view.
So
by
controlling
who
can
access
the
node
by
controlling
authorization
around
what
application
spaces
can
be
started
around?
What
the
the
different
users
can
do.
B
The
administrative
rights
around
container
making
sure
that
container
resources
are
done
properly,
that
the
server
is
hardened
up
front,
that
there
is
element
of
intrusion,
detection,
that
process
separation
is
actually
just
a
partial
list
of
all
the
security
benefits
that
open
ship
survive
and
it's
really
cut
across
both
the
operational
and
the
network
side.
So
what
that
allows
us
to
do
as
people
who
want
to
run
applications
in
containers
is
really
not
think
about
the
stuff
that
we
used
to
think
about,
which
is
how
do
we
harden
an
operating
system?
B
How
do
we
make
sure
that
we
have
consistency
in
the
administrative
right?
How
do
we
make
sure
that,
at
once
we
put
a
server
out
there?
It
doesn't
really
change
over
time
and
and
might
introduce
security
risks
that
were
not
initially
there,
so
OpenShift
and
and
admittedly,
also
other
container
platforms
but
open
ships
in
general
is
very
much.
Security
focused
doing
a
lot
of
good
work
for
for
making
sure
that
the
defaults
of
darker
that
that
may
not
be
as
secure,
are
actually
addressed
and-
and
it
really
gives
confidence
to
actually
on
the
platform.
B
But
that's
just
one
side.
That's
just
a
platform:
their
applications
themselves
are
still
the
applications,
organizations
still
develop
applications
in
containers
and
that
code
has
nothing
to
do
with
Dockers
or
red
hats
or
or
kubernetes,
or
anything
that
that
they
configure
the
configuration
of
the
platform
can
address.
The
applications
are
still
applications,
and
you
know
80.
B
The
prepackaged
images,
the
things
that
go
out
of
the
development
world
and
then
being
put
on
a
particular
server.
A
particular
node
through
a
deployment
is
not
well
understood.
There's
not
a
lot
of
transparency
in
the
way
that
applications
are
written
in
containers,
especially
the
way
that
they
are
put
together
with
the
operating
system,
and
that
creates
a
lot
of
uneasiness
to
security
operations
because
they
just
don't
fill
the
day
of
control
and
that
that
feeling
is
because
they
really
don't
know
where
security
fits
in
the
process.
Security
has
very,
very
good
history.
B
So
the
traditional
security
tools
that
are
being
used
to
view
the
environment,
to
assess
the
risk
of
the
environment
are
not
in
use
and
then
because
there's
a
lot
of
open
source
usage,
some
of
it
being
assembled
as
a
platform
like
open
shift.
Some
of
it
can
be
instantiated
just
as
an
open
source
component.
That
also
creates
an
easiness
for
for
security.
I'd
like
to
be
able
to
point
a
little
bit
about
you
know
the
process,
because
in
the
pre
container
world
you
used
to
basically
build
your
code
and
not
the
top
line
there.
B
You
can
do
some
static
analysis,
evaluate
the
code,
make
sure
the
decoding
practices
are
in
place
and
then
you
would
compile
a
package
or
a
component
that
can
then
be
run
on
a
server
that
was
provisioned
beforehand.
So
somebody
would
provision
a
server
configure
all
the
necessary
operating
system.
They
would
put
you
know
Java
on
it.
If
that's
the
case,
they
would
put
the
application
server
on
it.
B
If
that's
the
case,
any
type
of
middleware
that
is
required
assess
the
risk
corrected,
configure
it
properly,
and
then
these
two
things
gets
married
and
then
deployed,
and
after
that
deployment
is
done,
there
is
still
an
opportunity
to
then
take
a
look
at
the
configuration
security
and
another
security
parameters
for
for
servers
and
then
fix
them.
While
the
server
is
in
production,
containers,
work
very
differently
and
in
the
container
world,
the
coding
and
static
analysis
still
should
happen.
Right
we
are
talking
about.
B
Applications
are
still
written
in
in
programming
languages
that
can
benefit
from
static
analysis
code
still
it
could
be
to
be
compiled,
but
then,
when
building
an
image
when
doing
a
docker
build.
This
is
where
the
risk
assessment
comes
into.
Play
it
can't
be
done
later
in
the
process,
because,
once
the
container
is
instantiated
once
the
deployment
is
started
once
pods
are
instantiated
in
the
in
the
kubernetes
environment,
it
becomes
almost
impossible
to
patch
them
and
really
shouldn't,
because
containers
really
should
not
be
touched
after
they
rolled
out.
B
So
what
we're
doing
is
we're
now
moving
security
from
the
very
end
of
the
process
into
the
kind
of
beginning
middle
of
the
process,
and
that
represents
a
change.
It
not
represents
a
change
that
needs
to
have
both
the
procedural
and
process
and
communication
practices
in
an
organization
to
support
it,
but
it
also
requires
some
software
solution
that
can
provide
the
right
visibility
into
where
the
process
is.
So
what
are
we
actually
doing
about
it
and
what
is
awkward
doing
about
it?
And
why
are
we
educating
the
market
in
order
to
embrace
containers?
B
Well,
we
want
to
answer
the
the
needs
of
security
people
and
make
them
feel
comfortable
with
deployments
of
containers,
so
what
the
security
people
want.
They
want
safe
images
from
trusted
sources,
images
that
can't
be
tampered
with
images
that
we
know
what
the
components
are.
Common
security
practices,
like
all
the
things
that
open
ships
can
do,
making
sure
that
no
out-of-band
change
can
happen
to
the
environment
that
there
is
right,
localization,
Network
segmentation
to
make
sure
that
whatever
sensitive
data
you
have
is
still
segmented,
still
segregated
and
safeguarded.
B
Anything
that
we
need
to
do
in
an
environment
container
or
not,
especially
if
it's
a
regulated
in
scope
environment
needs
to
be
audited,
so
that
we
can
find
root,
cause
analysis,
but
just
provide
the
data
for
demonstrating
compliance.
A
lot
of
the
rules
for
security
and
I
know
if
you're
coming
from
the
DevOps
side
team
arbitrary,
but
that's
the
universe.
We
live
at
a
lot
of
times.
You
just
need
to
provide
data
for
compliance
because
you
need
to
provide
that
data.
B
So
all
of
these
have
been
developed
over
the
years
to
support
the
server
environment,
the
VM
environment
and
the
same
process
actually
happened
when
we
moved
from
physical
servers
to
to
virtual
machines.
All
these
questions
need
to
be
answered
and
it
took
a
little
time
for
security
people
to
come
on
board,
and
this
is
where
we
are
with
containers,
but
we
want
to
accelerate
that
process
and
we
want
to
make
sure
that
we
give
security,
people
and
DevOps
people
as
well.
B
B
And
this
is
a
very
complete
list.
But
at
a
very
high
level,
when
you
build
a
container
when
you,
when
you
do
a
darker,
build
make
sure
that
the
code
is
done
right.
Make
sure
that
you
we
have
a
good
understanding
of
what
goes
into
the
image.
It
starts
from
the
from
line
really
understanding
what
the
base
image
is
and
and
and
then
understand
what
other
components
will
be
built
on
it
all
the
way
to
the
payload
of
the
application
as
containers
are
promoted
from
environmental
environment
or
also
in
the
pipeline.
B
We
need
to
make
sure
that
our
assessment
is
still
valid,
so
preventing
any
change
or
tampering
with
an
image
is
something
that
will
need
to
be
done
all
the
way
up
to
the
rollout
to
the
node.
When
we
deploy
to
the
nodes,
the
nodes
themselves
are
our
operating
systems.
They
don't
have
as
many
components
as
as
operating
system
that
basically
carry
payloads
of
complete
applications,
but
there
is
still
you
know
a
lot
of
times
an
SSH
service
out
there.
There
is
still
the
ability
to
run
operating
system
commands.
B
So
what
I
like
to
do
is
kind
of
dive
into
each
of
those
those
areas
from
an
application
security
point
of
view
and
mention
how
well
we
can
execute
them
in
a
openshift,
kubernetes
environment,
but
but
also
in
a
natural
docker
environment.
The
same
things
really
really
need
to
happen.
What
open
ship
the
topping
off
with
is
is
by
providing
a
lot
of
the
controls
that
docker
doesn't
provide
by
default
and
making
them
available.
B
So
the
first
thing
after
a
actually
before
an
image
is
built,
is
to
figure
out
where,
where
the
image
is
coming
from,
and
how
do
we
want
to
build
it
so,
by
by
selectively
designing
the
build
process
of
the
container
image,
we
need
to
make
sure
that
the
the
images
are
secure,
that
the
base
images
are
secure,
that
whatever
we're
building
on
is
something
that
is
not
going
to
bring
with
it
a
set
of
vulnerabilities
or
sort
of
figurations.
That
is
not
in
line
with
the
best
practices
of
the
organization.
B
We
want
to
make
sure
that
we
register
those
images
so
that
only
approved
based
images
can
be
used.
Scan
vulnerabilities
of
the
entire
environment,
share
information
between
developments,
SEC
and
ops,
and
basically
get
a
good
visibility
into
the
entire
system.
If
we
get
good
visibility
for
it
transparent,
then
we
have
a
much
better
chance
of
that
environment
of
being
seen
as
secure
and
being
seen
is
something
that
security
feels
feels
comfortable
with.
So
on
that
note,
it
really
all
starts
with
the
development.
B
So,
let's
go
into
a
an
environment,
and
you've
probably
seen
that
before
this
is
Jenkins.
Jenkins
is
a
is
a
CI
tool
that
basically
drive
the
the
steps
in
which
an
application
is
is
done,
and
there
is
a
way
to
with
acqua
to
provide
a
service
that
those
processes,
the
CI
processes
or
actually
anybody
else-
can
ping
and
and
get
an
instant
assessment
of
an
image.
So
this
is
a
build
that
was
done
in
Jenkins
and
this
build
basically
starts
with
the
pull
of
the
base
image.
So
this
is
the
base
image
that
we're
pulling.
B
We
are
then
running
a
the
aqua
client
container
called
scanner
CLI
to
do
an
assessment
on
the
base
image,
make
sure
that
it
complies
with
policy
and
make
sure
that
it's
registered
is
something
that
is
approved
for
use.
We
are
now
collecting
all
those
packages
that
that
was
in
the
base
image
and
we
can
provide
information
if
the
base,
if
the
base
images
is
okay
to
use.
In
this
case
it
is,
we
are
then
doing
the
build.
So
that's
pretty
normal,
we're
doing
the
build.
We
are
copying
some
file.
B
This
is
not
a
very
robust
build,
but
actually
we're
copying
some
files,
installing
nginx,
putting
in
the
nginx
command
and
so
on.
Building
the
the
server
I'm
actually
pushing
it
into
the
registry
and
then
we're
going
to
do
an
assessment
on
it
and
you
can
do
the
reverse.
You
could
also
you
know,
do
the
assessment
for
then
decide
if
you
want
to
push
it
through
the
registry?
B
B
B
The
end
of
the
build,
usually
because
there
are
things
that
need
to
be
done,
but
for
our
purposes
this
this
is
where,
where
where
the
build
is,
is
finished
successfully
and
what
we're
doing
is
we're
still
providing
that
that
level
of
vulnerability.
But
right
now
we
see
that
their
scores
are
pretty
low
and
there's
nothing
there.
That
violates
the
policy
and
therefore
the
images
is
allowed
to
continue.
B
Maybe
somebody
decided
at
one
point
to
to
do
a
new,
build
or
experiment
with
a
building
the
same
environment
or
the
same
application
on
a
different
based
operating
system.
So
in
this
case
you
know
I'm
building
it
on
Debian
and
not
not.
Alpine
Debian,
of
course,
has
a
different
way
of
doing.
Application
comes
with
some
vulnerability
sets
and
so
on,
but
for
my
organization
in
this
demo,
Debian
is
really
not
assessed
right,
I,
don't
know
what
that
is
security.
Has
it
really
evaluated
it?
B
So,
even
though
it
has
the
same
amount
of
vulnerability
as
the
image
that
provided
that
that
was
allowed
to
proceed
in
version
2
version,
3
may
not
have
a
much
bigger
vulnerability
posture,
but
it
is
something
that
security
has
an
assessed
yet
so
we're
not
only
dealing
with
vulnerabilities
here,
we're
also
dealing
with
the
configuration
and
the
base
image
and
in
assessing
whether
or
not
that
is
acceptable
for
for
the
organization.
What
I'd
like
to
do
is
take
a
look
at
at
the
Aqua
side
of
things.
B
So
this
is
what
the
CI
side
of
things
in
the
Aqua
side
of
things.
We
have
our
demo
application
here.
Let
me
just
sort
it
by
alphabetically
and
we
have
the
same
information
in
the
Aqua
ISO
demo
number
one
is
disallowed
because
of
a
cv.
E2
is
okay
and
three
is
disallowed,
because
it's
not
using
an
approved
base
base
image.
B
All
of
these
actually
corresponds
to
a
an
image
assurance
policy
that
can
have
many
parameters,
but
the
ones
that
I
chose
to
use
in
this
demo
is
the
fact
that
there
are
some
vulnerabilities
that
should
be
blocked
and
that
these
are
the
approved
based
images
that
can
be
used
in
my
environment.
All
the
way,
if
I
wanted
you,
if
I,
if
I
I
build
it
on
Debian
with
if
I
use,
Devon
Jesse,
that
build
would
have
been
successful,
because
that
is
an
approved
base
image
right.
B
So
sometimes
it's
not
really
the
type
of
the
operating
system,
but
security
may
be
a
little
bit
behind
in
assessing
the
compatibility
of
newer
versions
of
the
OS
as
a
as
a
good
base
and
and
that
just
takes
time,
because
security
need
some
time
to
do
their
work.
That's
something
that
organizations
will
need
to
negotiate
and
make
sure
that
we
have
the
right
versions
in
place.
B
So
this
is
the
damage
policy
and
that's
why
we
have
the
some
of
the
tags
available
to
use,
and
some
are
not
another
thing
that
that
we're
providing
with
aqua
is
is
some
information
that
ops
and
security
might
want
to
know
about
the
image
as
a
whole.
So
it's
not
just
the
Devon
durability.
Foster
is
here
and
we
can
take
a
look
and
we'll
see
a
little
bit
the
vulnerabilities
and
what
they're
and
what
information
we
get
on
them,
but
just
the
packages
that
are
deployed
in
that
image,
some
of
the
metadata
about
this
image.
C
B
Of
work
to
provide
good
understanding
of
what
the
vulnerability
is
and
what
might
be
the
impact,
and
you
can
see
that
we
have
several
types
of
vulnerabilities.
Actually
cv
is
just
one
of
them,
so
we
are
using
white
source
as
our
one
of
our
sources
for
code,
that
that
is
not
really
operating
system
based,
but
really
some
package
base
so
and
we
can
give
you
some
fixed
solutions
and
advice
on
how
to
address
them.
We
are
correlating
the
red
head
vulnerabilities
with
the
NPD
vulnerabilities.
B
So
here
we
have
another
vulnerabilities
where
there
is
correlation
between
between
Red
Hat
and
the
CVS,
something
to
to
kind
of
make
a
note
is
that
sometimes
there
are
vulnerabilities
that
there's
no
agreement
on
and
there's
not
a
lot
of
agreement
in
the
vulnerability
space
inside.
So
what
we
have
at
aqua
is
we've
done
the
work
to
address
some
of
the
things
that
are
negligible
and
may
not
be
something
that
you
need
to
worry
about,
and
in
this
case
the
if
you
scanned
it
with
with
basic
any
any
type
of
vulnerability
scanner.
B
This
will
go
to
is
going
to
pop
up
on
this
version
of.
But
you
know
red
hats
no
longer
consider
this
to
be
a
security
issue,
because
there
are
maybe
other
factors
that
mitigating.
So
that
is
something
that,
as
a
development
organization
or
as
ops,
you
may
not
know
the
exact
impact
of
a
particular
vulnerability.
B
That's
why
we
need
to
have
collaboration
between
DevOps
and
security
to
just
make
sure
that
we
we
are
on
the
same
page,
but
we
are
arming
you
with
a
lot
of
information
in
order
to
make
the
argument
that,
if
you
do
need
to
use
a
component,
then
then
you
can
use
a
component
and
you
can
allow
and
you
can
allow
it
to
run
in
your
environment.
So
at
the
end
of
the
day,
we
want
our
images
to
be
secure.
So
you
want
to
get
an
agreement
that
an
images
is
okay
to
run.
B
B
Images
that
have
been
assessed
and
images
that
have
the
security
posture
is
known,
approve
them
based
on
the
risk
and
also
maintain
the
integrity
of
the
image,
so
that,
if
somebody
changes
it
or
the
name
changes,
we
can
detect
that
and
make
sure
that
the
images
is
proof
for
use
before
we
run
it.
So
we.
B
Three
demo
images,
let's
kind
of
run
through
that
pretty
quickly,
so
what
we
can
do
is
we
can
pull
our
demo
1.0
image
and
try
to
run
a
container
from
it,
and
we
get
the
message
that
you
know
we
don't
have
permission
to
execute
it,
because
this
is
an
unauthorized
image.
So
so
demo
1.0,
as
you
remember,
is
disallowed
and
the
message
was
you
know
we
won't
be
able
to
run
it
and
that's
that's
how
we
won't
be
able
to
run
it.
B
B
You
know
we
have,
you
know
the
ones
auto
version
and
the
2000,
but
if
you
try
to
run
that
two
data
version,
it
still
tells
us
that
this
is
an
unauthorized
image
and
the
reason
why
we
know
that
is
in
the
course
of
assessing
the
security
of
an
image
and
getting
all
the
vulnerability
information.
What
Apple
is
doing
is
actually
doing
a
hash
of
the
file
system
in
El
all
the
individual
file
and
then
a
complete
digest
of
that
image.
B
And
what
we're
doing
is
we
are
providing
a
state
for
each
of
those
images,
so
a
state
can
be
either
registered,
it
can
be
unregistered
or
it
can
be
an
invalid
digest,
and
in
this
case
we
have
a
are
one.
Other
image
is
registered,
it's
the
same
image,
but
it's
blocked
because
it's
disallowed,
my
two
meadow
image
actually
very,
very
iffy
right,
because
the
the
server
digest
is
one
thing
we
have
looked
at
it
before
but
locally.
It
doesn't
look
like
what
we
expect
and
therefore
we
would
block
the
the
running
of
it.
B
The
only
way
really
to
run
this
image
is
to
to
pull
it
again
and
that's
the
two
data
image
and
then
we
get
our
hello
world
and
then
that
image
becomes
registered.
So
it's
not
only
the
ability
to
understand
what
the
risk
posture
of
an
image
in
the
pipeline,
but
we
also
need
to
have
our
engines.
Our
nodes
only
accept
images
and
deployments
that
are
allowed
to
use,
and
we
have
the
ability
to
then
stop
images
that
are
not
allowed
to
use
or
that
are
different
than
what
we
we
expect
them
to.
B
One
of
the
things
that
aqua
provides
as
a
the
compliance
view
is
that
we
can
do
the
same
view
across
all
the
nodes,
and
this
is
my
my
host
images
view
and,
and-
and
you
can
see
that
there
are
you
know,
a
few
of
them
are
not
like
the
others
right.
Some
of
them
are
not
registered.
Some
of
them
are
not
registered
and
don't
comply
with
policy.
This
is
really
not
what
we
want
to
see.
We
want
to
see
something
that
is
more
in
line
with
the
rest
of
my
survey
environment.
B
You
know
my
number
3
server
is
probably
the
best
one,
because
I
didn't
put
anything
on
unauthorized
on
it.
This
is
really
what
we
want
to
see
we
want
to
see
is
everything
is
registered
and
everything
complies
with
the
policy.
The
same
view
by
the
way
can
be
done
on
on
containers.
So,
on
every
running
container,
we
have
the
ability
to
see
whether
or
not
it
complies
the
policy
or
it
comes
from
a
registered
image.
B
So
this
is
the
phase
where
we're
able
to
basically
say
that
everything
that
we
deploy,
everything
that
we
ship
to
a
particular
node
is
something
that
a
we
expect
and
B
has
passed
the
organization's
security
policy,
which
would
make
everybody
a
lot
more
comfortable
in
can
run
in
the
environment.
In
addition
to
that,
the
deployment
can
be
done
a
lot
of
times
with
automation
in
the
kubernetes
environment.
B
It
really
should
be
done
with
automation,
but
we
want
to
separate
automation
from
from
human
actions,
so
not
allowing
access
to
the
node
controlling
who
can
again
privilege
if
you
do
allow
access
to
the
node
make
sure
that
we
limit.
You
know
what
permissions
volumes
networks
can
be
used
in
the
course
of
a
deployment
and
basically
give
you
a
lot
of
an
audit
trail
and
that's
another
thing
that
that
aqua
can
do,
because
our
ability
is
to
audit
everything
that
happens
in
the
dock
of
engine
itself.
B
So
this
is
the
the
audit
log
from
the
last
few
minutes
and
you
can
see
that
I
had
a
block,
because
my
demo
too
was
was
disallowed.
Everything
else
is
successful.
So
another
thing:
if
you
are
working
in
a
kubernetes
environment,
you
expect
the
user
context
to
be
the
user
context
of
kubernetes
to
do
all
the
heavy
lifting
around
changing
and
starting
and
stopping
containers.
B
So
it's
really
easy
to
identify
if
there
is
a
user,
a
named
user
that
is
doing
any
of
that
work
and
that
of
course,
can
be
funneled
into
a
log
aggregator
or
security
information
management
platform
and
then
takes
from
there
and
correlated
with
with
the
rest
of
the
environment.
So
preventative
controls
are
great.
The
detective
controls
the
ability
to
see
the
logs
is
also
very,
very
useful
because
it
provides
us
with
the
ability
to
then
prove
that
our
controls
are
working
and
then
we
get
to
running
containers
themselves
right.
B
So
we've
seen
that
the
images
are
good
enough
to
run
because
we've
done
a
security
assessment
on
them.
We
know
that
they
haven't
changed.
We
know
that
they
are
run
by
authorized
services
or
authorized
people,
but
when
a
container
is
running,
there
is
a
lot
of
things
that
that
the
container
still
can
do
right.
It's
still
running
software,
it's
running
software,
that's
a
lot
of
times
exposed
to
incoming
traffic,
and
we
want
to
make
sure
that
our
container
is
is
run
really
according
to
plan.
B
We
want
to
prevent
any
significant
drift
between
the
container
and
the
image,
because
we
really
should
not
be
patching
or
doing
any
changes
to
a
container,
and
then
we
just
want
to
understand
what
the
usage
data
is
and
that's
not
usage
around
resources,
but
really
who's
using
what
and
and
whether
or
not
there
is
any
misuse
of
the
container.
Basically
in
attempts
to
co-opt
it
to
do
something
that
it's
not
just.
B
It
is
not
supposed
to
do
so
understanding
all
that
aqua
is
really
providing
those
controls,
while
a
container
is
running
and-
and
one
of
the
first
thing
that
we
want
to
do
is
just
kind
of
get
a
baseline
on
what
a
container
is
doing.
So
if
we
take
a
look
at
our
list
of
images
here,
I
have
WordPress
as
one
of
the
images
and
if
I
just
start
a
wordpress
instance.
B
One
of
the
things
that
that
happen
is
that
this
wordpress
instance
we
are
starting
to
get
some
telemetry
from.
So
we
are
getting
on
some
usage
information
from
it.
We
are
getting
all
the
executables
that
it
was
run
and
that
will
run
and-
and
you
can
see
that
you
know
work
with
a
pretty
heavy
application.
It
does
contain
a
lot
of
processing
and
web
server,
but
even
that
there
may
be,
you
know,
22
or
something
or
12
processes
that
need
to
run.
We
can
understand
what
the
networking
requirements
are.
B
Is
there
any
environment
variables
that
were
passed
belong
to
the
container
and
what
user
accounts
it's
running
on?
This
is
actually
not
a
very
good
image
because
it's
running
on
the
root,
we
want
to
make
sure
that
that
doesn't
happen
in
production,
but
let's
take
a
look
at
the
resources
right
now
so
now
now
we
have
an
idea
of
you
know
when
WordPress
is
running
really
what
it
needs.
B
We
see
there's
quite
a
lot
of
executables
there.
It's
actually
not
as
bad
as
some
of
the
other.
You
know
full
operating
system,
but
it's
more
than
the
application
needs
right.
So
one
of
the
things
that
we
need
to
ask
ourselves
is:
do
we
want
to
run?
You
know
every
single
executable,
just
because
it's
in
the
image,
but
another
very
important
question
is:
do
we
want
to
allow
those
executables
to
change
right
so
now
I'm
route
inside
of
a
container?
B
You
know,
there's
namespaces
here
so
I'm
not
route
on
the
host.
I
really
can't
do
a
lot
of
damage
on
the
host,
but
but
I
can
do
quite
a
few
damage
to
the
container
right.
I
can
I
can
take
your
LAN,
for
instance,
which
is
a
pretty
innocent
command,
but
I
can
do
like
a
copy,
let's
copy
that
another
executable
or
you
know,
maybe
download
an
executable
or
do
something
that
is
going
to
add
some
code
to
the
container.
B
That
was
not
found
in
image
and
then
let's
try
to
run
it
well,
we
can't
run
it
and
the
reason
why
we
can't
run
it
is
that
one
of
the
fundamental
policies
in
in
aqua
is
to
prevent
drift
between
the
container
and
its
image.
So
one
of
the
ways
to
allow
for
a
more
free
usage
of
containers
is
to
limit
what
can
be
done
to
them
once
they're
their
instantiated.
B
So
even
if
I,
even
if
I
change
the
line
itself
like
let's
say,
let's
copy
pink
to
a
LAN,
for
instance,
so
we
could
use
a
LAN
while
it
was
the
right
command
now
we
can't
use
it.
So
all
of
these
things
are
designed
to
make
sure
that
if
a
container
is
running,
instantiated,
there's
very
little,
it
can
be
exploited
by
by
that
container
and
that
that's
called
drift
revention.
This
is
actually
what
allows
us
to
then
go
back
to
our
list
of
running
containers
and.
B
Do
some
search
right,
let's
search
for
a
vulnerability,
we're
able
to
search
throughout
the
environment
for
a
particular
vulnerability
and
and
get
all
the
containers
that
run
from
it.
This
is
an
instant
impact
analysis.
We
can
go
into
the
containers
and
and
look
for
a
particular
package
or
an
executable
and
look
at
all
of
those
that
did
run
Python,
and
this
is
relying
on
the
fact
that
you
know
we
know
that
the
container
is
based
on
an
image
we've
already
pre-assess
the
image.
We
know
the
security
posture
of
the
image.
B
We
know
the
components
of
the
image
and
we're
also
preventing
any
addition
of
executables
that
can
be
run
from
the
internet
or
from
anywhere
else
or
even
something
that
was
written
as
a
script
inside
of
the
of
the
container.
So
the
idea
is
that,
in
order
to
maintain
that
assurance,
that
images
are
known
only
known
images
can
run,
only
containers
can
run
from
known
images,
and
they
cannot
change
from
the
known
images.
B
So
this
is
a
profile
that
is
based
on
on
JBoss,
and
we
can
see
that
the
files
for
it
are
actually
just
seven
executables
that
it
needs
to
run.
We
can
add
a
lot
more
things
to
the
profile.
We
can
add
whether
or
not
the
container
needs
networking
at
all.
If
we
can
add
read-only
files,
if
there's
a
configuration
file
in
the
container
that
should
not
change,
we
can
control
the
executable
list.
We
can
control
the
user
context
in
the
container
right
WordPress
run
as
root.
Jboss
is
a
little
bit
better.
B
There
is
a
user
ID
that
that
is
specific.
To
that.
This
is
the
parameter
that
tells
us
not
to
run
executables
in
the
original
image.
We
are
preventing
running
with
privileges,
so
this
is
in
the
case
that
a
container
instantiate
s
privilege
outside
of
the
open
shift
controls,
and
then
we
can
add
things
like
a
second
profile,
which
can
be
a
little
bit
more
granular
than
su-lin
can
run
per
repository.
B
That
is
that,
if
you
run
our
application-
and
you
know
we're
going
to
supply
some
parameters
to
it
and
we're
going
to
give
it
a
name,
give
the
port
and
so
on,
so
it's
a
little
bit
more
in
line
with
how
a
deployment
would
look
like.
But
then
let's
try
the
same
thing:
let's
try
to
do
a
docker
exec
and
try
to
do
basically
what
we
did
with
WordPress.
B
So
this
is
my
app
and
I
want
to
run,
wait
and
I'm,
getting
a
permission
denied
after
that,
and
that's
because
you
know
root
is
not
an
authorized
user,
for
this
container
root
is
something
that
should
be
reserved
to
basically
anything.
Nothing
like
really
a
container
ship
should
not
be
run
at
all
the
truth.
If
we,
if
we
eliminate
that
what
we're
doing
is,
we
are
doing
a
failover
to
the
user
that
is
defined
in
the
image
and
that's
the
JBoss
user.
B
So
now
we
are
in
the
container,
but
you
can
see
there's
a
bunch
of
permission
denied
there
and
that's
because
you
know
anything
else,
you
know
paying
LS
PS
curl
is
really
not.
She
really
shouldn't
run
right,
even
though
it's
available
inside
of
the
operating
system,
it
really
shouldn't
run
and
the
reason
why
it
should
run
is
because
it's
not
in
line
with
what
this
container
is
supposed
to.
Do.
It's
not
in
the
list
of
authorized
actually
executables.
B
In
this
case,
this
images
is
is
not
well
built
like
if
we,
if
we
add
or
let's
say
that
we
just
move
this
to
an
audit
only
and-
and
we
save
this
now-
we
do
have
LS
and
the
bin
directory
is
just
huge
right.
There's
a
lot
of
stuff
in
there
so
coming
that
I
probably
should
have
mentioned
the
beginning.
Is
that
size
really
does
matter
right?
The
smaller
images
usually
have
less
of
an
attack
vector.
This
has
a
huge
attack
vector.
B
Anything
here
can
either
have
a
vulnerability
and
can
be
exploited
if
you're,
using
big
images,
which
sometimes
there's
a
reason
to
limiting
the
processes
that
can
run
to
something
that
is
only
required
for
that
image
is
going
to
greatly
improve
our
our
our
the
security
posture
of
the
entire
environment.
So
let's
go
back
and
reapply
my.
B
Policy
here
and
and
let's
take
a
look
at
it,
how
we're
actually
passing
parameters
to
to
to
a
container
so
secrets
management
is
something
that
is
talked
about
a
lot
I
mean
in
the
last
docker
con
I
must
have
had
you
know,
50
conversations
on
secret,
management's
alone
and,
and
there
are
some
organizational
issues
with
using
the
built-in
ticket
management
inside
of
the
the
orchestration
tools.
Now
that
they're
not
good,
it's
just
that
they
don't
play
nice
with
the
rest
of
the
the
environment,
so
as
an
alternative
to
that.
B
What
what
aqua
is
doing
is
we're
using
our
capabilities
to
interface,
into
containers,
to
provide
some
aspect
of
Secrets
distribution
and
the
way
that
we
do.
That
is
that
we
have
our
ticket
distribution
on
the
front
end
and
as
far
as
the
nodes
are
concerned,
and
our
back
end
can
be
a
variety
of
integration,
so
it
could
be
a
hash
acog
fault.
It
could
be.
B
You
know
the
Amazon
key
management
services
as
your
key
management
services,
or
or
maybe
even
our
our
own
internal
database,
that
can
provide
those
secrets
and-
and
they
really
live
outside
of
the
orchestration,
because
security
sometimes
wants
to
control.
That
right.
Orchestration
may
be
a
little
bit
to
control
by
ops,
but
if
you
run
our
application,
what
we're
seeing
here
is
that
we
have
our
user
here,
which
really
should
not
be
encrypted.
We
have
a
token
here
which,
maybe
should
not
be,
should
be
encrypted.
B
We
have
something
that
is
coming
from
a
vault
somewhere,
so
if
we
do
basically
a
docker
inspect
on
my
application
and
let's
do
grep,
so
it
didn't
get
a
big
block
here,
you
can
see
that
the
the
unencrypted
is
still
unencrypted,
that
whatever
is
tokenized
so
tokenized
and-
and
my
token
here
is-
is
encrypted,
and
we
really
can't
see
it
anywhere
outside
of
the
of
the
container.
So
where
is
this
secret?
Coming
from
this
secret
is
coming
from,
in
this
case
the
aqua
internal
database?
B
It
could
come
from
hasha
cobalt,
it
could
come
from
the
key
management
stores
and
first
of
all,
we
get
tracking,
which
container
is
using
it.
So
that's
really
important,
because
if
that
leaks
out,
we
want
to
know
the
impact
and-
and
we
can
actually
change
the
value.
So
we
can,
you
know,
put
here
something
OpenShift
and
save
the
change
and
that
gets
transmitted
directly
to
the
the
container.
B
So
if
we
go
into
the
container
and
take
a
look
using
the
exact
command
at
the
environment
variables,
we
are
getting
that
that
value
that
is
being
decrypted
and
handed
off
to
to
the
container.
So
that
secrets
management
is
something
that
can
be
done
external
to
to
the
orchestration.
It
can
something
it
could
be
under
the
control
of
security
and
not
ops.
You
can
mix
and
match.
B
So
if
there
are
secrets
that
are
very,
very
operational
in
nature,
and
you
still
want
to
keep
them
in
kubernetes
and
make
sure
that
they're
part
of
the
system,
you
can
still
use
them.
If
there
are
secrets
that
are
more
corporate
that
need
to
be
put
into
a
separate
vault
or
there
needs
to
be
rotation
on
them,
that
is
more
automated,
then
you
have
the
ability
to
do
it
without
what
we
require
is
actually
distributing
that
secrets
to
to
the
environment
and
everything
that
we've
done
so
far
is
also
audited.
B
So
we
audited
the
fact
that
we've
changed
a
secret,
so
that's
important,
that's
something
that
security
really
needs
to
know
is.
Whenever
secrets
are
rotated,
we've
seen
all
the
docker
inspects
in
start
command.
We
did
a
lot
of
detection
of
the
the
file
execution,
so
this
is
where
LS
was
was
permitted.
This
is
where
all
the
file
execution
inside
of
the
containers
were
blocked
and,
and
you
can
see
the
difference
between
the
detect
of
the
block,
we're
getting
the
actually
original
user.
B
So
this
is
me
logging
on
to
the
container
to
the
host,
even
though
I
did
a
lot
of
work
inside
of
the
container.
So
that's
something
that
usually
the
the
compiler
organization
is
interested
in
to
figure
out
who
did
what
in
the
environment,
but
we're
getting
a
lot
of
information
and
really
it
at
the
core
of
it
is
the
notion
that
that
we
have
the
opportunity
to
do
better
security
with
containers.
So
if
you
have
security,
people
that
are
resistant,
please
tell
them
that
you
know
container
is
actually
good
for
security
and
somebody's
been
doing.
B
Security
for
20
years
is
saying
that,
and
that
is
that
we
can.
We
can
do
all
of
these
capabilities
I'm
not
going
to
read
them
out
loud,
but
but
these
are
the
things
that
that
are
important
for
security,
and
these
are
the
things
that
we
can
execute
in
a
containerized
environment
which
we
should
provide
us
with
the
ability
to
run
meaningful
workloads
in
scope,
applications
and
applications
that
are
subject
to
regulations
based
on
the
security
needs
of
the
organization.
So
I
hope
this
was
been
a
beneficial.
Please
visit
our
course
ENCOM.
B
A
Well,
thank
you
very
much
Debbie.
This
has
been
it's
been
it
really.
I
I
got
the
demo
when
we
were
at
KU
con,
but
I
didn't
go
into
this
much
depth.
So
I
really
appreciate
it.
It's
great
stuff
that
you
guys
are
doing
they've
been
a
couple
of
questions
and
I
think
what
might
be
the
easiest
thing
to
do
is
if
I
unmute
Peter
who's
been
asking
most
of
those
questions
with
Peter
you're
unmuted.
Now,
why
don't
you
go
ahead,
Peter
and
try
and
frame
your
question
and
I
actually
kick
off
some
conversation.
D
It's
basically
I'm
trying
to
figure
out
the
scope
of
the
scanning.
A
lot
of
the
questions
we
care
is
about
compliance
and
that's
the
concern.
It's
not
just
the
CDs,
but
it's
also
is
this
server
actually
allowable
to
go
into
production.
Hence,
is
it
following
government
standards
for
whatever
security
standards
you
have
to
apply?
D
So
that
means
that
the
scanner
when
we
do
an
Ole
Miss
cat
scan,
for
instance,
is
mostly
interested
in
the
configuration
of
the
components
that
are
running
not
just
that
they
are
running
on
the
right
and
the
latest
final
reason
a
lot,
but
they
might
not
allow
bad
things.
Examples
could
be
allowing
route
logins
and
SSH
or
sha-1
or
even
256,
for
encryption
stuff
that
I'll
not
allow
by.
You
know
it's.
D
B
So
we
are
evaluating
the
the
makeup
of
the
image
in,
in
addition
to
the
file,
so
I
didn't
really
go
into
the
policy,
but
but
one
of
the
things
that
you
can
do
actually-
and
you
said
that
is-
is
you
know,
identify
images
that
are
was
that
control
right
here
identify
images
that
are
defaulting
to
run
as
root
right.
So
that's
equivalent
of
the
you
know
is
route
open
to
SSH
on
on
a
server.
B
So
we're
actually
using
this
as
a
preview
in
the
course
of
the
next
couple
of
months
we're
going
to
release
a
version
that
has
the
ability
to
run
code,
snippets
and
and
and
script
snippets
to
assess
the
security
of
certain
elements
of
the
operating
system
and
also
ask
app
support
if
you're,
using
that,
if
you
know
how
to
use
that
language
to
provide
a
structure.
That
can
be
that
we
came
SST
the
image
against
and
we
definitely
recognize
the
fact
that
vulnerabilities
are
not
the
end-all
be-all
of
the
security
posture.
B
A
So
keep
us
posted
I'm
almost
to
the
end
of
the
hour
and
I,
don't
see
any
other
questions,
I'm
wondering
if,
if
you
have
anything
else,
you
want
to
add
Seve
or
if
pêche
wants
to
butt
in
and
ask
any
questions
at
all
or
anther
and
I
think
that
most
of
the
questions
got
answered
in
the
QA,
and
they
were
questions
that
preceded
things
that
you
then
explained
in
the
slides
and
in
the
demo.
So
I
think
we
did
a
pretty
good
job
of
covering
up
everything
off
today.
I
had.
C
B
A
All
right
and
thanks
for
asking
Lucy
anyone
else,
have
any
questions.
It's
not.
You
can
always
check
these
folks
out
on
aqua,
PSICOM
or
jump
on
slack
there's
a
couple
of
them
that
are
in
the
slack
channel
for
openshift
commons
or
hit
them
up
on
the
mailing
list
as
well.
So
again,
seve
and
apesh
and
I.
Think
rainy
was
on
there
as
well
answering
questions
thanks
very
much,
and
we're
really
pleased
to
have
you
guys
as
members
of
the
open
ship
Commons
and
look
forward
to
hearing
more
from
you
in
the
future.