►
Description
In this Tech N’ Talk, Red Hat’s Kirsten Newcomer discusses the 10 most common layers in a typical container deployment and ways to build security into each layer. These layers include: The container host, content, and registries, the CI/CD process, the container platform, networking, storage, and API management.
Organizations are rapidly adopting containers to more easily develop and manage the applications that drive business value. However, as with any newer technology, enterprise use requires strong security at every stage of the lifecycle. Securing containers is a lot like securing any running process. You need to think about security throughout the layers of the software stack. You also need to secure your CI/CD pipeline. You need defense in depth.
This discussion coverseach of these 10 layers, and Kirstin uses Red Hat’s OpenShift container platform to illustrate how to deliver continuous security for containers.
A
Hi
everybody
and
welcome
again
to
another
check-in
talk.
Second,
hop
is
a
podcast
when
you've
started
this
summer,
bringing
you
some
fresh
ideas
and
some
deep
dives
on
things,
mostly
cloud
native
II,
but
from
all
sort
of
different
parts
of
the
technology.
That
is
that
we
get
to
use
in
our
cloud
native
applications,
so
sometimes
we'll
sidetrack,
but
today
we're
not
sidetracking
we're
really
going
to
go
for
some.
An
interesting
conversation
with
the
person.
Gonna
come
up
who's,
as
it
says,
on
the
screen,
a
security
strip
strip,
strategists
and
very
passionate
about
security.
A
Here
at
Red
Hat
with
me
and
she's
kindly
offered
to
reprise
a
presentation,
she's
done
all
10
layers
of
container
security,
which
is
rockin,
awesome
and
I'm
really
glad
to
have
Kirsten
here
with
me.
So
I
want
to
let
her
do
her
talk.
You
can
ask
questions
in
the
chat
and
we'll
have
live
Q&A
at
the
end
and
a
bit
of
a
conversation,
so
without
any
further
ado.
Welcome
to
techyv
talk.
First.
B
I'm
gonna,
just
kind
of
start
not
by
talking
about
what
containers
are,
because
I
am
assuming
that
most
of
you
already
have
a
good
idea
about
what
containers
are
and
if
you
don't
I
know
that
there's
some
terrific
content
already
recorded
and
available
on
OpenShift
Commons
that
you
can,
where
you
can
learn
more.
But
what
what
I
did
want
to
call
out
really
is
that
containers
change,
how
we
develop,
deploy
and
manage
applications,
and
for
that
reason
they
really
affect
both
the
development
and
the
ops
team,
and
there
are
different
advantages
for
each
team.
B
We
typically
think
about
containers
as
really
providing
advantages
for
the
application
development
team
right
you
get
to
package
everything
up
in
it
with
all
its
dependencies.
In
one
place
you
can
deploy
that
same
container
to
any
environment.
You
want
your
application
to
run.
You
really.
You
know
minimize
the
configuration
images
that
you
have
and
it
makes
it
much
easier
to
share
your
contents
and
your
components,
components,
but
there's
also
real
advantages
for
the
ops
team
right.
A
container
application-
it
has
a
smaller,
lighter
footprint.
B
B
Other
note
is
that
I'm
going
to
be
talking
about
these
are
all
things:
the
security
things
that
I'm
talking
about,
or
all
things
that
you
can
do
in
a
DIY
container
environment,
but
I'm
also
going
to
use
openshift
as
an
example
for
how
its
implemented
with
a
container
platform
and
how
that
makes
it
easier.
But
certainly
these
are
things
that
can
be
done
both
DIY
and
with
container
platform,
we're
going
to
start
with
the
container
host
and
multi-tenancy.
B
So
many
of
our
security
teams
have
really
gotten
comfortable
with
how
to
secure
VMs
and
to
get
a
little
more
concerned
when
the
technology
shifts
to
containers,
and
so
from
that
point
of
view,
the
OS
that
you
deploy
your
containers
to
really
does
matter.
You
want
to
be
sure
that
you're,
taking
advantage
that
you
have
an
OS
that
provides
security
capabilities
and
that
you
take
advantage
of
those
security
capabilities.
B
So,
of
course,
you
know
from
the
RedHat
point
of
view,
that's
Red,
Hat,
Enterprise,
Linux
and
and
Red
Hat
Enterprise
Linux
atomic
host
a
couple
of
the
the
key
capabilities
to
think
about
there,
and
since
this
is
a
tech,
audience,
Vic
and
I
can
get
a
little
bit
into
these
Linux
namespaces
provide
the
fundamentals
of
container
isolation.
The
namespace
provides
abstraction,
makes
it
appear
to
the
processes
within
that
namespace
that
they
have
their
own
instance
of
global
resources.
So
that's
a
key
element
to
rely
on
yet
seen.
B
Linux
is
used
to
keep
containers
isolated
from
each
other
and
from
the
hosts.
It
allows
administrators
to
enforce
mandatory
access
controls
for
every
user
application
process
and
file.
It's
the
brick
wall.
That's
going
to
stop
a
process
if
it
manages
to
break
out
of
accidentally
or
on
purpose
the
namespace
abstraction.
You
know
really
concrete
example
here
is
that
selinux
provided
mitigation
of
a
discovered
container
on
entry
vulnerability
for
those
of
use
who
really
want
to
go
there?
You
can
look
it
up.
B
It's
CVE,
2016,
9
962,
but
selinux
was
able
to
prevent
processes
from
accessing
host
content,
even
if
those
container
processes
managed
to
gain
access
to
actual
file.
Descriptors
and
Dan
Walsh
did
a
great
blog
on
this.
Also
something
that
you
can
look
up:
control
groups
again
because
you're
you
one
of
the
advantage
containers
it's.
You
can
run
multiple
applications
on
a
single
system
and
because
they're
packaged
with
their
own
dependencies.
You
don't
have
to
worry
about
configuring.
B
Cgroups
allow
you
to
ensure
that
containers
won't
be
stomped
on
by
another
container
on
the
same
host
and
then
finally,
the
secure
computing
mode
profile
can
be
associated
with
a
container
to
restrict
available
system
calls.
So
really
all
of
these
are
security
capabilities
that
you
can
use
for
any
running
process,
and
in
this
context
you
want
to
think
of
containers
as
another
running
process
and
apply
those
security
features
and
functions
and
principles
that
you
would
apply
to
any
running
process.
B
It's
worth
noting
that
so
I'm,
sorry
another
another
thing
to
think
about.
If
you
want
to
further
enhance
your
security
and
minimize
your
attack
surface
read
you
know,
atomic
host
is
is
the
host
for
you
right.
That
is
a
container
optimized
operating
system,
and
it
really
makes
it
much
easier
to
it's.
It's
specifically
tuned
for
containers
and
really
only
has
the
packages
that
you
need
to
run
containers
and
it
there
is
no
young
install,
so
people
can't
go
out
there
and
arbitrarily
add
different
packages
to
the
environment.
B
A
further
proof
point
of
the
security
feature
is
available
with
Red
Hat
Enterprise
Linux
is
that
rel
7.1
received
Common
Criteria
certification,
including
certification
of
the
Linux
container
framework
support.
So
all
of
these
kinds
of
things
have
been
talking
about,
and
that's
it
so
I'm
not
talking
about
the
docker
runtime
when
I
say
that
right,
but
all
of
these
surrounding
capabilities
were
the
first
Linux
distribution
to
receive
that
Common.
Criteria
certification
for
the
Linux
container
frameworks
support
okay,
so
that's
the
OS
and
multi-tenancy.
B
B
So
Red
Hat
provides
a
large
number
of
certified
images,
including
the
rel
base,
images,
various
language,
runtimes,
middleware
databases
and
more
on
the
Red
Hat
container
catalog
Red
Hat
certified
containers
around
anywhere
Enterprise
Linux
runs
from
bare
metal
to
BMS
and
they're,
supported
by
Red
Hat
and
our
partners.
So
the
container
image
content
that
we
deliver
is
packaged
from
known
source
and
Red.
Hat
provides
security
monitoring
on
these
packages,
so
you
can
see
in
this
screenshot.
B
The
grade
of
each
container
image,
the
detailing
you
know
information
you
might
need
about
any
known
vulnerabilities,
so
that
you
can
be
sure
that
you
are
aware,
before
you
download
the
content
of
the
security
aspects
of
that
container
and,
of
course,
we
keep
up-to-date
with
security
fixes
and
patches,
and
we
will
rebuild
those
container
images
whenever,
whenever
security
fixes
are
released,
as
you
can
see
in
this
in
this
screenshot
version,
3.4
1315,
you
know,
new
vulnerability
was
discovered.
The
released
3,
4
.
13
16,
with
the
vulnerability
fix
and
the
grade,
went
back
up.
B
Of
course,
they're
going
to
be
times
when
you
need
content
that
Red
Hat
doesn't
provide,
and
in
those
situations
you
recommend
you
use
container
scanning
tools.
There
are
a
number
of
them
out
there
on
the
market.
Many
of
them
used
continuously
updated
vulnerability,
databases
and
they
will
identify
denta,
fie,
the
open
source
components
inside
the
container
image
and
identify
any
known
vulnerabilities
associated
with
those
components.
B
Some
of
the
scanners
will
also
do
commercial
software,
but
but
a
majority
of
them
are
really
focused
on
on
open
source
content,
so
you
can
think
about
things
like
J
frog,
x-ray,
twistlock,
aqua
security,
Blackduck
hub.
These
are
some
of
the
things
out
there
for
a
limit,
I'm,
sorry
for
Red
Hat
content.
Also,
we
provide
a
scanner
called
open
s,
cap
that
you
can
use
as
well.
So
hey.
A
B
You've
got
a
bunch
of
content
that
you
may
have
downloaded
from
a
public
source,
but
that's
really
only
the
starting
point
for
the
applications
that
you're
building
the
applications
that
really
drive
the
business
value
for
your
company
right.
So
you
want
to
be
sure
that
you
manage
access
to
and
promotion
above
the
container
images
that
your
team's
use,
both
the
ones
you
download,
but
also
the
ones
you
build,
just
as
you
would
manage
access
to
and
promotion
of
any
other
type
of
binary.
B
So
you
can
do
that
using
a
container
registry
or
a
binary
repository.
That
knows
how
to
work
with
containers-
and
you
start
to
see
both
terms
used
in
the
industry
these
days,
but
typically
they're,
referring
to
things
like
J
frogs,
artifactory,
Sona
type,
Nexus,
binary,
repository,
docker
trusted
registry
and
openshift
comes
with
an
integrated
registry
that
we
call
the
registry.
You
can
use
to
manage
your
container
images,
but
OpenShift
also
integrates
with
the
popular
binary,
repos
registries
container
registries
that
are
available,
the
ones
that
I've
already
mentioned.
B
So
when
you
think
about
a
registry,
you
want
to
be
sure
that
it
provides
that
it
enables
you
to
store
and
see
security
metadata
on
your
images
that
you
have
access
controls
that
you
can
do
things
like
say
you
know,
hey
this
image.
Is
this
image
is
okay
for
deployment
in
production,
but
this
this
image,
this
other
image,
is
only
okay
for
deployment
and
a
development
environment
because
it
hasn't
been
fully
vetted
yet.
B
Similarly
builds
are
a
really
important
part
of
the
security
process.
Right,
as
with
any
application,
managing
production
builds,
is
a
key
element
of
your
of
your
process.
You
need
a
definitive,
build
environment
for
your
production
container
deployment.
You
really
don't
want
developers
doing
docker,
build
on
their
laptops
and
then
deploying
that
build
to
production,
because
that's
not
a
reproducible
build
environment.
B
So
you
want
to
integrate
your
you
want
your
container
build
process
to
use
the
kind
of
automated
and
integrated
CI
process
that
you
do
for
other
types
of
applications
and,
if
you're
not
doing
that,
yet
you
should.
You
should
really
be
looking
into
it.
There
are
a
lot
of
great
tools
for
automating
automating.
Your
builds
and
doing
continuous
integration.
B
Okin
shift
comes
with
an
integrated
instance
of
Jenkins
4c
and
can
also
be
integrated
with
your
own
CI
environment.
If
you
prefer
and
again,
if
you're
doing
this
yourself,
you
can
put
together,
you
know
a
process
that
includes
your
preferred
CI
tools.
You
don't
have
to
have
an
a
container
platform.
We
just
think
it
makes
it
easier
if
you've
kind
of
got
everything
in
one
place.
There's
less
for
you
to
maintain.
You
can
let
somebody
else
maintain
it.
B
So,
once
you've
got
a
build
completed,
the
image
should
be
pushed
to
a
registry
just
as
we've
been
talking
about
earlier,
and
that
can
be
done
automatically
when
you
use
open
shift.
For
example,
you
also
want
to
be
sure
again
that
you
proactively
check
container
contents
over
time
right.
New
vulnerabilities
are
identified
daily,
so
just
because
you
knew
your
image
was
vulnerability.
Free
at
the
time
you
did,
your
build
doesn't
mean
it's
going
to
stay
vulnerability
free,
even
if
the
code
hasn't
changed
at
all.
B
Again,
you
want
to
leverage
tools
like
open
s,
cap
black
dub,
J,
frog
x-ray
as
part
of
your
CI
process.
Just
like
you
would
integrate
other
types
of
security
tools
like
security,
static
analysis
tools
like
IBM,
rational
AppScan
or
HP.
Fortify.
Look
that
that
you
look
to
it
that
you
use
to
look
at
your
own
source
code.
B
You
want
to
use
these
other
types
of
security
tools
to
introspect
the
container
images
that
you're
working
with
another
really
great
thing
about
containers
that
actually
can
help
you
to
enhance
the
security
in
in
a
more
automated
fashion
is
the
layered
packaging
model
so
that
layered
packaging
model.
If
you
work
in
a
regulated
environment
that
requires
separation
of
concerns,
in
some
cases,
the
layered
packaging
model
really
helps
you
do
that.
You
can
have
your
operations
team
be
responsible
for
the
core,
build,
perhaps
the
the
rel
images
that
they
pull
down
from
Red
Hat.
B
You
can
have
your
architects
be
responsible
for
adding
the
middleware
content,
so
so
layering
the
middleware
content
on
top
of
that
core
build
image,
and
then
your
app
dev
team
really
only
needs
to
think
about
the
code
that
they
need
to
write
to
to
develop
that
application
and
and
built
that
full
container.
And
when
you
take
this
kind
of
approach
and
you
have
a
fully
integrated
or
automated
apologies-
a
fully
automated
CI
process.
You
can
also
look
at
triggers
to
help.
You
know
when
to
rebuild
containers,
so
those
triggers
really
kind
of
span.
B
Both
the
container
build
and
the
container
deployment
topic
I'm
going
to
talk
about
them
a
little
bit
here,
but
before
I
do
that,
let's,
let's
talk
again
about
some
additional
things
you
need
to
do
around
around
deployment
and
continuous
deployment
for
security.
Let's
say:
you've
run
your
CI
process.
You've
run
all
your
scanners.
There
are
no
known
security
issues
with
the
images
that
the
contents
of
the
images
that
you've
built
and
you're
ready
to
push
to
deploy,
you're
ready
to
deploy
to
production.
B
Well,
it
may
be
that
without
realizing
it
you've
got
a
container,
an
application
container
that
requires
that
it
be
run
with
root
privileges.
In
order
to
to
do
everything,
it
knows
how
to
do,
but
your
security
team
or
your
production
team
has
a
policy
that
says
no
container
is
allowed
to
run
as
root
and,
in
fact
that's
a
really
good
security
best
practice
right.
Don't
let
your
containers
run
as
root.
B
Just
don't
do
it,
so
you
want
to
leverage
any
capabilities
you
can
to
do
things
like
automatically
prevent
privileged
deployment
of
privileged
containers,
so
kubernetes
and
open
chef
to
come
with
something
called
security
context
constraints
which
allow
you
to
do
that
automatically
right.
You
can
it.
You
can
monitor
that
I'm
sorry,
so
you
can
make
sure
that
the
selinux
context
is
defined
for
a
container.
You
can
check
to
see
if
it
requires
root
prigs.
If
it
does,
you
can
prevent
it
from
being
deployed
whole
sets
of
things
that
you
can
do
here.
B
It's
also
worth
mentioning
at
this
point
for
any
of
you
who
are
really
familiar
with
selinux.
A
lot
of
folks
are
used
to
turning
off
in
their
base
rail
images,
because
not
every
application
knows
how
to
run
in
an
SELinux
environment.
One
of
the
nice
things
about
the
containerized
application
running
on
open
shift
is
that
openshift
manages
SELinux
for
you
and
container
izing.
That
application
means
that
you
can
take
advantage
of
the
protections.
Selinux
provides
you
without
having
without
having
to
worry
about
those
SELinux
elements.
B
So
it
really
gives
you
the
ability
to
have
a
much
more
secure
environment
so
back
to
triggers
and
thinking
about
image.
Registries
right,
you
want
to
monitor
those
image
registries
again
to
make
sure
that
you
become
aware
if
a
newly
discovered
vulnerability
shows
up-
and
if
it
does,
you
want
triggers
in
place
to
make
sure
the
appropriate
people
know
about
it.
So,
let's
take
a
look
at
an
application.
That's
building!
That's
that's
built
using
the
three
container
image
layers
that
I
talked
about
earlier
core
middleware
and
finally,
the
application
layer.
B
If
an
issue
is
discovered
in
the
core
image
and
you've
got
these
kind
of
monitoring
capabilities
available,
you'll
get
notification
that
that
core
image
has
a
known
vulnerability.
You
also
ideally
would
get
notification
that
a
new
image
is
available
from
the
original
public
repo.
You
pulled
that
core
image
from
these
are
capabilities
that
that
openshift
supports.
B
Yet
you
you
deploy
that
new
one
you
migrate,
users
over,
you,
make
sure
everything's
up
and
running
good
and
production,
and
then
you
can
take
down
that
vulnerable
container.
On
the
other
hand,
if
it's
a
severe
vulnerability,
you
may
decide
you
want
to
stop
that
container
right
away.
While
you
go
through
this
process,
so
by
leveraging
and
automating
your
continuous
integration
and
continuous
deployment
process
with
OpenShift
the
entire
process
of
me.
B
Let's
talk
a
little
bit
more
about
the
container
platform
if
you're
using
you
know
when
it.
One
of
the
big
reasons
for
using
a
container
platform
is
the
orchestration
features
that
help
you
manage
container
deployments
at
scale
right.
You
need
to
you,
you.
You
really
want
again
automation,
orchestration
to
help
manage
which
containers
should
be
deployed
to
which
hosts
monitoring
host
capacity.
You
know
container
discovery
knowing
which
containers
need
to
access
each
other
and
controlling
access
to
management
of
shared
resources,
monitoring
container
health,
so
all
of
these
things
are
typically
offered
through
your
orchestration
platform.
B
So
one
of
the
key
concepts
of
the
or
of
a
container
platform
in
this
orchestration
is
that
it's
the
master
nodes
that
that
really
have
all
of
this
controlling
and
capability
to
kind
of
manage
deployment
and
process
around
the
the
places
that
your
application
containers
are
deployed.
And
for
that
reason
the
masters
have
a
fair
amount
of
privilege
in
order
to
do
that
work,
so
you
really
need
to
be
sure
that
you
have
strong
multi
tenant
security
security
on
the
platform
itself.
B
B
Ideally,
you
know
an
x.509
certificate,
token-based
the
ability
to
use
project
quotas
to
limit
how
much
damage
a
rogue
token
could
do.
All
of
things
are
things
you
want
to
be
sure
you've
got.
Ideally,
you
also
want
to
be
thinking
about
a
platform
that
supports
image.
Signing
right
makes
it
easy
as
you
as
you
build
those
images
to
sign
them.
Maybe
you
use
external
signing,
but
you
also
need
to
verify
the
signatures
as
part
of
your
deployment
process
and
you
want
secrets
management.
So
this
is
a
place
where
the
OpenShift
has
some
capabilities.
B
Today,
right,
you
can
mount
secrets
into
containers
using
a
volume
plugin.
The
system
can
use
secrets
to
perform
actions
on
behalf
of
a
plot.
A
pod
at
CD
is
the
place
where
OpenShift
stores
tenant
secrets
today,
and
today
you
know
in
OpenShift,
35,
that's
not
at
CD
is
not
as
secure
as
many
enterprises
would
like
it
to
be.
So
this
is
a
place.
Red
Hat
is
investing
and
then
openshift
three
six
one
ships.
We
will
have
secrets
encrypted
at
rest
in
etsy
d.
B
Okay,
so
network
defense
right,
traditional
data,
centers
traditional
applications,
network
defenses,
is
a
big
part
of
the
way
the
security
team
thinks
about
this.
You
know
how
do
I,
how
do
I
manage?
How
do
I
protect
my
internal
environment
from
the
external?
How
do
I
segment
things
on
my
network,
but,
and
and
and
you
need
to
think
about
this-
for
containers
as
well.
B
That
said,
really,
we
think
one
of
the
best
ways
to
do
this,
given
the
scale
at
which
containers
are
coming
and
going
in
in
a
an
enterprise
environment.
Is
you
really
want
to
be
using
software-defined
networking
as
a
way
to
help
automate
this,
so
the
first
line
in
network
defense
comes
from
network
namespaces
and
with
okay?
So
sorry,
this
is
my
area
that
I'm
least
deep
in
so
I
rely
on
my
cheat
sheets
here.
B
A
Acronyms
and
they're
so
far,
yeah
and
just
to
slay
me
I
have
the
one
that
just
popped
up.
This
might
be
a
good
time
just
to
ask
it.
Edward
was
asking:
is
there
because
you
showed
us
the
registry
health
check
and
that
I
think
is
for
Red
Hat
images
for
Red
Hat
red?
Yes,
is
there
somebody
in
to
open
the
shift
or
at
all
third
party
stuff,
that
shows
that
would
have
a
health
page
for
container
images
or
something
similar
in
the
OpenShift
registry?
Oh
that's.
B
That's
yep,
that's
a
great
question.
There
are
a
couple
of
ways
to
show
security
data
in
the
open,
shipped
UI,
and
you
are
correct
that
the
Red
Hat
container
catalog
today
provides
the
health
index
just
on
RedHat
images,
and
we
may
extend
that
over
time
to
the
rest
of
the
images
that
are
available
from
the
Red
Hat
container
catalog.
All
the
images
are
supported,
but
the
health
index
is
only
available
on
Red
Hat
content.
B
So
when
it
comes
to
looking
at
security
data
in
open
shift
itself,
there
are
a
couple
of
places
that
you
can
can
see
that
show
up.
So,
for
example,
open
shift
comes
with
a
tool
called
cloud
forms
which
is
part
of
the
the
management
offering
for
from
Red
Hat
and
it,
and
it
helps
you
kind
of
manage
across
a
wide
variety
of
deployment.
Environments
and
openshift
is
one
of
the
ways.
I'm
sorry
cloud
forms
is
one
of
the
ways
you
can
run
open
gap
scans,
which
I
mentioned
earlier.
B
You
can
run
an
open
s,
cap
scan
and
if-
and
there
is
a
UI
I-
don't
have
a
screenshot
in
this
deck,
but
there
is
a
UI
where
you
will
see
the
results
of
that
scan
and
if
there's
a
known
vulnerability
discovered-
and
you
have
your
policies
set
appropriately,
you
can
prevent
deployment
of
that
vulnerable
image
that
you
know
there.
So
there
are
multiple
ways
to
prevent
deployment
of
vulnerable
images.
B
The
atomic
registry
also
has
a
GUI
and
I'll,
be
honest.
I'll
have
to
to
look.
You
know
get
one
of
my
colleagues
to
tell
me
exactly
what's
visible,
whether
the
the
metadata
that
I
was
talking
about
is
visible
in
the
GUI
through
the
CLI
I
will
look
into
that,
but
registries
like
Jay
frogs,
artifactory
registry
or
sauna
type
Nexus.
They
absolutely
do
show
you
that
kind
of
vulnerability,
data
and
many
of
the
scanners
have
integrations
so
that
you
can
see
some
of
that
data
from
other
third-party
scanners
in
those
registries.
B
Thanks
sure,
okay,
so
back
to
networks
and
namespaces
right.
So
with
network
namespaces,
each
collection
of
containers,
known
as
a
pod,
gets
its
own
IP
import
range
to
bind
to
which
allows
you
to
isolate
pod
networks
from
each
other
on
the
nodes
and
because
again,
the
proliferation
of
IP
addresses
and
ports
makes
networking
more
complicated.
When
you
have
a
large-scale
container
deployment,
we
really
strongly
recommend
using
Sdn
Software
Defined
Networking
to
help
you
handle
that
complexity.
B
B
That
said,
you
can
also
you
know
another
thing
that
comes
up
frequently
with
security
teams,
they're
used
to
using
network
scanners
as
part
of
their
protection
scheme
for
the
network
environment.
So
what
we
recommend
around
that
is
is
that
many
of
those
network
scanners,
if
they're
not
yet
designed
for
software-defined
networking
tools
like
those
and
others
like
them,
can
be
containerized
and
and
can
be
run
as
super
privileged
containers.
You
just
have
to
make
an
exempt.
You
know
a
special
policy
for
them
to
give
them
the
level
of
privilege
that
they
need.
B
But
it
is
one
of
the
things
to
think
about.
There's
there's
actually
a
lot
of
capability
available
in
these
in
these
solutions
and
and
so
definitely
worth
thinking
about
there.
Something
else
to
mention
quickly
right
is
that
there
is
the
ability
to
control
egress
traffic
using
either
a
router
or
a
firewall
method,
so
that
you
can
use
again
more
traditional
methods
such
as
IP
whitelisting,
and
you
might
use
that
to
control
which
users
have
access
to
certain
databases
and
introduced
as
a
tech
preview
in
OpenShift
3.5.
B
There's
a
new
network
policy
plug-in
that
improves
upon
the
way
the
OBS
multi-tenant
plug-in
can
be
used
to
configure
allowable
traffic
between
pods.
So
the
network
policy
allows
configuration
of
isolation
policies
at
the
level
of
individual
pods,
and
this
is
still
in
tech,
preview
and
OpenShift
3.6,
but
again
lots
of
great
capabilities
here
and-
and
this
is
a
space
where
you
know
a
traditional
security
team-
will
be
particularly
interested.
B
Ok,
trying
to
keep
an
eye
on
the
time
to
here,
but
I
think
we're
good
storage
right.
There's
a
lot
of
conversation
today
about
stateless
applications
and
etcetera,
etcetera.
But
you
know,
there's
still
a
lot
of
kick
butt
applications
out
there
that
need
storage
and
even
if
you're
doing
a
stateless
app,
you
might
want
to
store
some
information
somewhere
and-
and
so
that's
really
where
attached
storage
comes
in
and
of
course
you
need
to
secure
your
attached
storage.
B
So
a
container
platform
with
orchestration
tools
again
makes
that
easier.
Openshift
has
plug-ins
for
multiple
flavors
of
storage,
including
NFS,
AWS
elastic
blocks,
Dores
GCE,
persistent
disks,
cluster
FS,
I,
scuzzy,
Seth,
cinder
and
they're.
The
way
in
which
you
protect
your
storage
volumes
really
varies
depending
on
the
type
of
storage,
so
a
persisted
volume
can
be
mounted
on
a
host
in
a
way.
That's
that
is
supported
by
the
resource
provider
such
as
read,
write
once
read.
Only
many
read
write
many
block
storage
such
as
EBS
GCE,
I
scuzzy.
B
You
can
use
your
SELinux
capabilities
to
secure
the
route
of
the
mounted
volume,
making
the
mount
of
volume
owned
by
and
only
visible
to
the
container
it's
associated
with
and
for
shared
storage.
Like
NFS
effort
lustre,
you
can
manage
that
by
adding
the
group
ID
of
the
persistent
volume
to
the
Supplemental
groups
of
the
pod
so
and
then
by
default.
You
want
to
be
sure
that
data
in
transit
is
is
encrypted
which,
on
OpenShift
it's
encrypted
via
HTTP
for
all
components.
Communicating
between
each
other.
B
You
really
want
to
think
about.
How
are
you
going
to
get
appropriate
governments
of
those
api's
and
one
approach
that
we'd
recommend
is
using
an
API
management
tool?
So
openshift
now
includes
a
containerized
version
of
the
three
scale:
api
gateway
that
helps
you
manage
api
security,
so
3
scale
gives
you
a
variety
of
standard
options
for
api
authentication
and
security,
and
in
addition,
you
have
the
option
to
use
application
and
account
plans
that
let
you
restrict
access
to
specific
endpoints
methods,
services
and
apply
access
policies
to
group
of
youth
groups
of
users.
B
One
of
the
cool
things
about
application
plans,
if
you
use
an
API
gateway,
is
that
they
allow
you
to
set
rate
limits
for
API
usage
and
control
traffic
flow
for
groups
of
users.
So
this
is
a
way
that
the
you
know
and
you
can
also
automatically
trigger
overage
alerts.
So
that's
that's.
A
can
sometimes
be
a
good
indication
if
you
get
a
sudden
spike
in
usage.
You
know
you
want
to
be
able
to
stop
that
quickly.
B
B
Okay,
federated
clusters.
This
is
actually
a
future's
looking
a
forward-looking
slide
and
something
that
Red
Hat
and
the
kubernetes
community
are
working
on.
Federation
is
useful
for
very
large
scale,
high
availability,
global
deployments
that
require
multiple
clusters
and
multiple
availability
zones.
You
can
use
federated
clusters
to
the
concept
as
you
can.
You
can
use
this
to
manage
more
than
one
data
center
in
different
regions,
but
also-
and
that
could
be
with
with
the
same
public
cloud
provider
or
federated
clusters-
might
will
also
help
you
manage
across
different
public
cloud
providers.
B
So
some
of
the
key
elements
that
are
in
the
works
here
are
federated
secrets,
giving
you
the
ability
to
automatically
create
and
manage
secrets
across
all
the
clusters
in
a
Federation,
making
sure
that
the
secrets
are
kept
globally
consistent
and
up-to-date,
even
when
some
clusters
are
offline
and
federated
namespaces
right,
creating
namespaces
in
the
Federation
control
plane
to
make
sure
they're
synchronized
across
all
the
clusters
in
the
Federation.
Once
again,
this
is
forward-looking.
This
is
something
that's
that's
in
progress.
B
There
are
elements
of
this
in
kubernetes
today
and
red
again
is
working
with
the
community
to
get
these
ready
for
enterprise
support.
I
mentioned
the
security
ecosystem
earlier
so
again,
if
you're,
if
you're
a
security,
professional
or
you're
talking
to
your
security
team,
this
whole
series
of
security
tools
that
the
security
teams
are
already
using
today
or
that
they
they
really
want
to
be
sure,
can
be
used
in
a
containerized
environment.
And
so
some
of
these
include
special
identity
and
access
management
tools.
B
Of
course,
most
of
us
think
about
things
like
Active
Directory,
but
there
are
also
tools
that
are
focused
on
privileged
access.
Management
and
security
teams
often
use
those
tools
to
make
sure
not
only
that
they're
controlling
privileged
access,
but
that
they
can
audit
it.
I
mentioned
earlier
external
certificate
authority.
Authority
is
external
vaults
and
key
management
solutions.
The
container
content
scanners
that
I've
talked
about
as
well
as
phone
with
other
types
of
vulnerability
management
tools.
There
are
also
some
container
runtime
analysis
tools,
both
aqua
security
and
twistlock.
B
Do
some
container
runtime
analysis,
those
those
are
useful
and
again
you
want
to
be
integrating
with
your
security
teams,
information
and
event
monitoring
system.
So
you
want
to
be
collecting
the
logs
from
your
container
deployment,
both
the
platform
and
the
applications.
But
but
in
particular
the
platform
is
probably
the
most
interesting
thing
to
your
security
team.
You
want
to
flow
that
information
into
that
information
and
event
monitoring
environment
so
that
it
can
be
aggregated,
aggregated
and
viewed
in
the
tools
that
that
the
teams
are
used
to
again.
B
You
want
you
want
to
be
sure
that,
as
you
look
for
melee,
you
know
really
look
to
productize
and
and
broad
scale
deployments
that
you
are
thinking
about
solutions
that
help
you
do
this
kind
of
integration.
So
it's
said
you
know.
We
think,
of
course,
that
open
shipped
is
one
of
the
best
ways
that
you
can
do
that
we
support
those
all
the
kinds
of
capabilities
that
I've
been
describing,
and,
in
addition,
of
course
you
can.
You
know
do
this
yourself
by
using
some
of
the
open
source
community
tools.
A
So-
and
this
has
been
great
for
me
because
it
pulled
this
sort
of
pulls
all
of
that
together
and
and
I
mean
I.
I
really
appreciate
it.
So
thank
you
for
that.
Edward
is
asking
a
question
you
mentioned,
like
you
mentioned
twist,
lock
and
accra
sect
and
jay
frog
and
a
few
others
as
well,
but
she's
wondering
if
you
have
any
thoughts
about
cystic,
falco
or
other
utilities
to
help
you
know
you
get
to
play
with
all
of
them.
So
in
your
in
your
life,
those.
C
Okay,
yeah
sure,
thanks
for
this
Kirsten
yeah
we're
looking
at
some
utilities
to
help
monitor
containers
running
containers.
How
so
we
kind
of
found
utility
from
cystic
if
their
utility
that's
sort
of
like
a
TCP
dump,
but
they
also
have
another
product
called
Falco
which
allows
you
to
set
up
a
policy
and
alerting.
So
if
she'll
gets
spawned
up
in
a
container,
that
can
be
a
message
that
alerts
a
team
or
so.
B
Interesting
well,
they
both
I
will
definitely
make
a
point
of
learning
more
about
those.
It
sounds
to
me
that
they
are
a
Falco
at
least
would
be
complementary
with
something
like
black
cub
or
J
frog.
X-Ray,
twistlock
and
aqua
security
have
two
solutions
that
that
and
one
of
which
may
be
an
interesting
one
to
explore.
A
So
I
know
that
I
had
the
Cystic
folks
on
before,
and
you
know:
Bishop
Commons,
breathing,
so
I'll
post
a
Fed
word
I'll,
send
you
on
an
email.
If
you
share
your
email
with
me
with
some
links
to
that,
but
about
three
weeks
ago
the
Aqua
set
this
rice
did
a
Tekken
talk
and
he's
also
done
a
really
interesting,
open
source
project
under
aquas
X,
it's
in
their
github
repo
called
coop
bench,
which
takes
the
notice
I'm
gonna,
say:
click
the
center
for
internet
securities,
kubernetes
benchmarking
tests
and
automates
them
to
run
against
your
kubernetes.
A
A
really
interesting
project
you
might
want
to
take
a
look
at
that
too.
Bench
is
something
that's
also
out
there
and
you
could
possibly
take
a
look
at
and
I
know.
New
vector
is
also
using
those
security
benchmarks
in
their
offering.
So
there's
that
thing
about
security,
there's
so
many
angles
at
it,
then.
But
it's
interesting
to
see
the
different
approaches
people
take
and
your
question
earlier,
edward
about
the
dashboard,
stefan
and
I'd
love
to
see
a
visualization.
A
Even
it's
a
third-party
one
baked
into
OpenShift
as
well,
so
that
it
was
alerts
and-
and
that's
part
of
the
thing
like
in
am
normally
in
technic-
I'm
not
so
open
shifty,
but
one
of
the
things
is
open.
Ship
can't
be
everything
to
everybody,
so
we
really
love
working
with
these
third-party
folks
who
are
experts
on
these
things
and
integrate
very
easily
with
with
OpenShift
and
kubernetes.
So
there's
lots
of
there's
lots
of
content
out
there.
So
please
yeah,
absolutely.
B
A
comment
on
the
on
the
coop
bench,
the
CIA
s
benchmark.
Might
my
best
understanding
is
that
you,
you
use
those
benchmarks
really
for
making
sure
that
the
overall
deployment
environment
is
secured
after
the
platform
and
the
environment,
and
that
that
something
like
aqua
security,
twistlock
and
it
sounds
like
also
Falco-
are
more
about
the
behavior
of
the
application
and
Edward.
Is
that
right
that
Falco's
monitoring
the
application,
behavior
yeah.
C
B
A
A
B
A
A
B
Lucy
Koerner
does
an
awesome
presentation
on
using
not
just
cloud
forms,
but
cloud
forms:
ansible
insights
to
automate
the
configuration
of
the
initial
configuration
of
security
profiles
they're
using
using
openness
cap
and
then
to
audit
and
automatically
remediate
as
well.
So
she's
got
some
great
knowledge
in
that
space.
Yeah.
A
A
B
B
No
I
I
can
put
you
in
touch,
but
Alexandra
Shulman
is
VP
of
an
Innovation
Center
at
Citigroup
and
she's
a
great
person
and
and
of
course,
the
people
I'm
gonna,
think
of
are
in
the
security
space
but
she's
a
great
person.
She
doesn't
to
talk
about
the
implications
of
security.
You
know,
for
you
know,
cloud
native
apps
and
as
things
change,
you
know
what
are
the?
What
are
the
angles
to
think
about
there
so
she's
a
possibility,
perfect.
A
So
that
might
be
a
good
slot
to
try
and
push
her
into
doing
something
there,
because
coop
cons
coming
up
December
6th
7th
and
we
always
big
open
ship
gathering
the
day
before
sort
of
think
of
it
as
a
prep
session
for
coop
con
and
get
all
the
updates
before
you
go
in
so
then
you
can
go
you're
loaded
with
questions
so
well,
we'll
try
and
see
if
we
can
reach
out
and
get
some
of
those
folks
there
so
Kristin.
Thank
you
so
much
for
taking
the
time
today.
To
give
this
talk
it
really.
A
It
was
awesome.
I
can't,
thank
you,
know.
I'll
add
in
the
links
that
you
had
and
post
this
as
a
blog
post
along
the
slides
on
blog
that
open
ship,
calm
and
tweet
it
out
as
well
and
it'll
be
uploaded
on
YouTube
under
the
technical
on
flavor.
It's
sort
of
belong
with
the
lots
of
puzzle
there
again.
Thank
you
very
much.
My.