►
From YouTube: TL;DR NIST Container Security Standards - Elsie Phillips, CoreOS (Beginner Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
TL;DR NIST Container Security Standards - Elsie Phillips, CoreOS (Beginner Skill Level)
In September 2017, the National Institute of Standards and Technology issued a 63 page paper detailing their recommendations for container security. While it’s chock-full of recommendations all cloud native users should implement, it’s not a text most people will read. In this talk, Elsie Phillips from CoreOS will cover key takeaways from the report like the importance of using container-specific host OSs and using tooling specific to containers to monitor for vulnerabilities, as well as some suggestions for how to implement them within an organization.
About Elsie
Elsie herds the CoreOS Community and Co-Leads the Kubernetes Contributor Experience SIG. She's a northwest native who got her start in open source working at the Oregon State University Open Source Lab. In her free time she throws wild one woman dance parties and makes a mean vegan chocolate chip cookie.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
So
if
you're
a
little
confused
about
the
branding
on
the
slides,
that's
what
happened
and
I'm
also
a
co-lead
for
the
contributor
experience
sig,
so
I'm
have
a
mandatory
little
plug
to
do
here,
so
bear
with
me
come
help
us
improve
the
project
through
things
like
reading
the
developer,
guide,
building,
bots
and
automating
processes
and
running
the
mentorship
program.
We
meet
every
Wednesday
at
9:30
a.m.
Pacific
time
and
have
lots
of
work
for
new
contributors.
So
please
join
us,
okay
and
flug,
and
that's
how
to
get
a
hold
of
me.
A
A
Okay!
Now,
let's
get
down
to
business.
What
are
we
here
to
do
today?
So
first
we're
going
to
talk
about
what
this
paper
is
and
what
it
isn't.
And
then
we
are
going
to
talk
about
some
of
the
terminology.
They
use
in
the
paper
make
sure
that
we're
we're
all
operating
on
the
same
level
and
then
we're
gonna
get
into
the
really
fun
part
where
we
talk
about
how
everything
can
break
and
you
can
cry
tears
and
then
some
recommendations
for
how
to
possibly
prevent
those
tears
in
the
future.
A
Okay.
So
why
are
we
here?
In
the
summer
of
2017,
the
US
National
Institute
of
Standards
and
Technology
issued
its
first
report
on
container
technologies.
The
purpose
of
the
report,
according
to
the
authors,
was
to
explain
the
security
concerns
associated
with
application
container
technologies
and
make
practical
recommendations
for
addressing
those
concerns
when
planning
for
implementing
and
maintaining
containers.
A
It's
also
63
pages
long
well,
we
might
all
happily
sign
up
to
read
63
pages
of
a
novel
by
JK,
Rowling
or
Jr
Martin
technical
briefs
generally
do
not
top
most
people's
reading
lists,
but
it
totally
should
because
this
paper
is
awesome.
So
I'm
going
to
play
hype
woman
today,
I'm
going
to
be
the
bad
movie,
trailer
that
we
all
hate.
That
shows
all
of
the
really
cool
bits
in
hopes
that
you
will
come
see
the
the
full
thing.
A
So
what
will
we
be
covering
today?
Who
should
be
interested
in
reading
this
report?
The
answer
is
anyone
thinking
of
running
container
technologies.
So
what
does
this
paper
not
cover
and
that's
any
form
of
virtualization
other
than
application
containers
such
as
virtual
machines?
The
term
container
can
be
used
to
refer
to
concepts
such
as
software
that
isolates
enterprise
data
from
personal
data
on
mobile
devices
and
software
that
may
be
used
to
isolate
applications
from
each
other
on
desktop
operating
systems.
A
Well,
these
may
share
some
attributes
with
application
container
technologies
they're
out
of
the
scope
for
this
paper,
and
thus
this
talk
will
be
focusing
on
containers
for
server
applications,
so,
first
up
terminology,
so
most
of
you
are
probably
already
going
to
be
familiar
with
these
terms,
but
it's
important
that
we
all
be
on
the
same
page,
so
we're
going
to
quickly
level
set
first
up
virtualization.
This
is
the
simulation
of
the
software
and
our
Hardware,
upon
which
other
software
runs
application
virtualization.
This
is
when
multiple
discrete
apps
have
access
to
the
same
operating
system
kernel.
A
A
Immutability
immutability
is
an
important
concept
when
it
comes
to
containers,
containers
are
operated
in
a
stateless
way.
This
means
that
when
you
want
to
make
a
change
to
a
container,
that
container
is
destroyed
and
a
new
container
with
the
desired
changes
is
spun
up
and
deployed
in
its
place.
The
upside
of
this
is
that
it
enables
an
increase
in
deployment
velocity,
allowing
developers
and
support
engineers
to
make
and
push
changes
daily.
The
challenging
part
is
that
this
has
some
security
implications.
A
Container
runtimes
now
hosts
operating
systems
for
containers
have
binaries
that
create
and
control
the
environment
for
each
container.
The
runtime
acts
as
the
bridge
between
the
operating
system
and
the
individual
container
coordinating
the
parts
of
the
operating
system,
the
isolate
resources
and
resource
usage,
ensuring
that
each
container
is
isolated
from
other
containers
that
may
be
running.
The
runtime
eliminates
the
need
to
manually
create
all
the
necessary
configurations
and
simplifies
the
process
of
starting
stopping
and
operating
containers.
A
Ok,
so,
finally,
let's
dissect
this
container
architecture
and
lifecycle
phases
diagram.
So,
first
up,
we
start
out
in
developer
systems.
This
is
when
application
and
all
of
its
dependencies
are
built
and
placed
into
an
image
developers,
oversee
the
step
and
usually
set
up
a
continuous
integration
process
that
will
produce
images
that
have
had
their
components
tested
and
then
assembled
according
to
the
developer
written
manifest.
A
A
A
Orchestration
is
the
optional
next
step.
Orchestrators
enable
the
automated
pulling
of
images
from
registries,
deploying
those
images
into
containers
and
managing
the
running
of
containers.
Kubernetes,
as
we
all
know,
is
an
Orchestrator.
Finally,
we
get
to
hosts
which
run
and
stop
containers
is
directed
by
the
orchestrator
or
a
host
can
pull
an
image
directly
from
a
registry
for
a
container
runtime
bypass,
bypassing
orchestration.
A
A
For
example,
an
image
may
include
an
SSH
daemon,
which
exposes
the
container
to
unnecessary
Network
risk
embedded
malware
as
we
established
earlier.
Images
are
composed
of
files
and
libraries,
it's
possible
for
someone
to
intentionally
or
unintentionally
include
a
malicious
file
or
library
when
building
the
image
example
of
how
this
could
happen
is
the
use
of
a
base
layer
from
an
unknown
party.
That
malicious
component
would
have
the
same
level
of
access
as
the
orchestrator
components
of
the
image.
A
This
would
give
it
the
opportunity
to
attack
other
containers
or
hosts
in
the
environment,
embedded,
clear
tech
secrets,
components
of
an
application
may
use
secrets
to
ensure
secure
communication
when
an
app
is
packaged
into
an
image.
The
secrets
may
be
inadvertently
included
in
the
image
file
system.
This
poses
a
security
risk
because
anyone
with
access
to
the
image
could
parse
the
image
and
have
access
to
the
secrets
use
of
untrusted
images.
One
of
the
greatest
advantages
of
containers
are
their
ease
of
portability
and
reuse.
A
However,
when
a
container
is
from
a
third
party,
the
usual
risks
of
deploying
software
built
externally
still
apply.
For
instance,
there
could
be
malware
poor
handling
of
data
resulting
in
leakage
or
vulnerability
and
the
components
okay,
registry
risks.
Images
may
contain
sensitive
information,
such
as
proprietary
software
or
embedded
secrets.
If
the
connection
to
an
organization's
registry
is
insecure,
the
image
is
vulnerable
to
having
that
sensitive
material
exposed.
If
the
connection
is
insecure,
it
is
also
possible
for
a
man-in-the-middle
attack
to
be
executed,
allowing
for
the
network
traffic
to
be
intercepted.
A
Insufficient
authentication
and
authorization
restrictions,
so,
as
we
just
discussed,
images
may
contain
sensitive
information
if
the
authentication
and
authorization
in
place
for
a
registry
is
insufficient,
that
sensitive
material
may
be
stolen.
Additionally,
downstream
containers
or
hosts
could
be
affected
by
a
breach
of
a
registry,
since
that
is
where
all
the
images
are
being
pulled
from
Orchestrator
risks,
so
unrestricted
administrative
and
unauthorized
access.
Some
orchestrators
were
built
with
the
assumption
that
everyone
who
had
access
to
them
would
be
valid
users
and
administrators
and
gave
them
control
to
the
entire
environment.
A
This
opens
the
system
up
to
advertent
an
intentional
manipulation
by
those
who
shouldn't
have
access
poorly
separated
inter
container
network
traffic.
In
most
containerized
environments,
traffic
between
individual
nodes
is
routed
over
a
virtual
overlay
network.
This
overlay
network
is
typically
managed
by
the
orchestrator
and
is
often
opaque
to
existing
network
security
and
management
tools.
Although
an
encrypted
overlay
network
provides
many
operational
and
security
benefits,.
A
It
can
also
create
a
security
blindness
scenario
and
which
organizations
aren't
able
to
effectively
monitor
traffic
within
their
own
networks.
Also,
if
apps
of
different
sensitivity,
levels
such
as
a
public
facing
website
and
an
internal
treasury
management
app
are
using
the
same
virtual
network.
Sensitive
internal
apps
may
be
exposed
to
greater
risk
from
now
attack,
orchestrate
or
no
trust.
It's
important
that
the
trust
between
nodes
and
environment
retain
their
integrity.
The
orchestrator
is
the
most
foundational
node
in
the
cluster.
Improper
Orchestrator
configurations
may
expose
the
orchestrator
and
the
rest
of
the
environment
to
increased
risk.
A
Okay
container
risks
vulnerabilities
within
the
runtime.
These
are
particularly
perilous
because
this
thing
called
container
escape.
This
is
when
malicious
software
has
access
to
attack
resources
in
other
containers
or
the
host
operating
system
itself.
If
an
attacker
is
able
to
breach
the
runtime
itself,
then
they
could
alter
the
runtime,
so
they
have
access
to
the
containers
or
monitor
container
to
container
communications
app
vulnerabilities
a
container
may
be
compromised
due
to
a
flawed
application
within
it,
for
example,
a
containerized
web
app.
A
May
be
vulnerable
to
crop
cross-site,
scripting
vulnerabilities
and
a
database
front-end
container
may
be
subject
to
sequel
injection
when
this
occurs,
the
container
may
be
misused,
such
as
to
grant
unauthorized
access
to
send
of
information
or
enable
attacks
against
other
containers
or
the
host
operating
system
row
containers
this
happens
when
a
container
crops
up
where
it's
not
supposed
to
be.
This
typically
happens
in
development
environments
such
as
when
developers
launch
containers
as
a
testing
method.
When
these
containers
have
not
been
properly
configured
tested
and
scanned
for
vulnerabilities,
they
may
be
susceptible
to
exploitation.
A
When
these
containers
persist
in
the
environment,
without
developers
or
security
admins
awareness,
they
pose
an
additional
threat
host
operating
system
component
poner
abilities.
So
the
first
is
a
shared
kernel.
Containers
do
a
good
job
of
isolating
resources
at
a
software
level
because
they
use
a
shared
kernel.
However,
this
provides
a
larger
attack
surface
than
a
hypervisor,
even
when
the
host
operating
system
is
container
specific.
A
Improper
user
access
write,
writes
direct
management
of
a
host
of
a
host
where
the
user
bypasses
the
orchestrator
to
logon
directly
is
risky
because
it
allows
for
the
potential
for
them
to
affect
more
containers
and
they
intend
so
host
operating
system
file.
Tampering
host
volumes
are
put
a
greater
risk
of
file
tampering
when
containers
are
not
securely
configured.
For
example,
if
a
container
is
allowed
to
mount
sensitive
directories
on
the
host
operating
system,
that
container
can
then
change
files
and
those
directories.
A
So
the
first
recommendation
is
to
use
vulnerability
management
tools
that
are
specifically
designed
for
containers,
I'm,
going
to
say
that
again,
really
important
use
vulnerability,
management
tools
that
are
specifically
designed
for
containers,
conventional
vulnerability
management
tools
are
built
on
assumptions
that
just
don't
reflect
how
containerization
is
on
these
tools.
Often
miss
vulnerabilities
within
containers
because
of
this
good
tools
to
use
take
into
account
the
pipeline
based
approach
and
immutable
nature
of
containers.
The
second
is
to
adopt
tools
and
processes
that
ensure
compliance
with
secure,
secure
configuration
best
practices.
A
Ok,
how
do
you
secure
your
registry
against
some
of
those
vulnerabilities
that
we
talked
about
so
first
to
counteract
registry
registry
vulnerabilities,
configure
your
development
tools,
orchestrators
and
container
runtimes
to
only
connect
registries
over
encrypted
channels,
and
the
ultimate
goal
here
is
to
make
sure
that
all
data
push
to
and
pulled
from
a
registry
takes
place
between
trusted
endpoints
and
is
encrypted,
while
in
transit.
Next,
never
use
old
images
which
ensure
this
doesn't
happen.
Delete
from
your
registry,
any
images
that
are
old
or
unsafe.
A
The
best
way
to
do
this
is
an
automated
process
based
on
time
triggers
and
labels
also
give
images
and
mutable
names
that
specify
discreet
versions,
for
example,
use
my
app
2.3
or
my
app
2.4.
Instead
of
just
my
app.
As
we
all
know,
one
of
the
hardest
names
and
hardest
problems
in
computer
science
is
naming.
The
struggle
is
real.
Please
use
specific
names.
Third,
finally
require
authentication
to
access
any
registry
with
sensitive
images
also
require
authentication
to
write
to
a
registry
to
make
sure
that
only
safe
images
can
be
added
orchestrators.
A
The
first
recommendation,
the
authors
make,
is
to
restrict
administrative
access
to
the
orchestrator,
set
up
a
lease
privileged
access
model
where
users
are
only
granted
the
ability
to
perform
the
specific
actions
on
specific
hosts
containers
and
images
their
jobs.
Job
roles
require,
for
example,
the
testing
team
should
not
have
access
to
all
of
your
containers.
A
The
next
recommendations
are
related,
configure
your
Orchestrator
to
separate
network
traffic
by
sensitivity
level
and
then
isolate
deployments
to
specific
host
by
sensitivity,
level
and
then
finally,
configure
your
orchestration
platform
to
create
a
source,
a
secure
environment
for
the
apps
they
run
by
securely.
Introducing
nodes
into
the
cluster
have
a
persistent
identity
throughout
their
lifecycle
and
also
provide
an
inventory
of
nodes
and
their
connectivity
States.
They
should
be
designed
specifically
to
isolate
and
remove
a
compromised
node
from
the
cluster
without
disrupting
or
degrading
overall
cluster
operations.
A
Container
vulnerability,
countermeasures
first
set
up
monitoring
of
your
runtime
for
vulnerabilities
and
quickly
deal
with
any
detected
issues.
Runtimes.
The
vulnerabilities
are
particularly
dangerous
because
they
expose
all
the
containers
they
support
and
the
hosts
to
risk
ensure
that
the
orchestrator
only
permits
deployments
to
secure
runtimes
next
automate
compliance
of
container
runtime
configuration
standards.
This
could
be
achieved
by
using
tools
or
processes
that
continuously
assess
configuration
settings
across
the
environment
and
actively
enforce
them
running
containers
with
their
roots
and
read-only
mode
makes
them
easier
to
monitor
and
more
difficult
to
and
rounding.
A
A
Okay,
home
stretch:
how
do
the
authors
recommend
counteracting
host
operating
system?
Vulnerabilities
first
use
a
container
specific
operating
system
to
reduce
the
size
of
the
tax
surface,
keep
them
up
to
date,
monitor
them
and
their
components
for
vulnerabilities
and
quickly
fix
them
upon
detection.
Next
audit,
all
authentication
to
the
operating
system,
monitor
it
for
login
anomalies
and
log.
Privileged
operations
finally
run
containers
with
the
fewest
file
permissions
possible.
A
So
that's
it
for
this
talk,
but
there's
so
much
more
in
this
report
and
I
would
highly
recommend
all
of
you
go
out
and
read
it
again.
There
is
the
link
to
the
talk.
Thank
you.
I
want
to
reiterate
for
the
people
that
came
in
late.
Apparently
they
do
not
have
speakers
or
microphones
for
QA.
So
you're
welcome
to
come
up
and
talk
to
me
afterwards
or
quickly.