►
From YouTube: Operationalizing Kubernetes Security Best Practices
Description
As more companies scale up their Kubernetes adoption, they face growing security challenges. Kubernetes itself provides many native controls that can help organizations improve their security posture, but often they aren’t fully utilized.
On this webinar, we’ll discuss:
- how to avoid common pitfalls in scaling Kubernetes adoption across an organization
native security controls in Kubernetes and how to maximize their value
- ways to use the declarative nature of Kubernetes app specifications to increase security
- how Kubernetes provides a common language DevOps and Security teams can share to improve security without sacrificing speed or flexibility
- practical security controls you can adopt to reduce the likelihood and impact of attacks
A
Alright
looks
like
our
numbers
are
stabilizing,
so
let's
go
ahead
and
get
started.
Thank
you.
Everyone
for
joining
us
today,
I'd
like
to
welcome
you
to
today's
CN
CF,
webinar,
opera,
operationalizing,
Coover,
levees
security,
best
practices,
I'm
Kaitlyn,
Barnard
marketing
manager
at
CNCs
and
I'm,
going
to
be
helping
to
moderate
today's
webinar
I'd
like
to
welcome
today's
presenter
Connor
Gilbert
Senior
Product
Manager
at
stack
rocks
so
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
A
So
if
you
have
any
questions
or
comments
throughout
the
webinar,
there
is
a
Q&A
box
at
the
bottom
of
your
screen.
So
please
feel
free
to
drop
in
any
questions
that
you
have
and
we're
gonna
save
those
to
the
end,
and
then
we
will
get
to
as
many
as
we
have
time
for
the
session
is
also
being
recorded
and
will
be
sent
out
afterwards,
along
with
the
link
to
the
slides.
So
with
that
I'm
gonna
hand
it
over
to
Connor
to
kick
off
the
presentation,
I.
B
Could
morning
everyone,
my
name
is
Connor
Gilbert
and,
as
Katelyn
mentioned,
I
work
on
the
product
team
at
Stack
rafts
a
container
and
current
IT
security
company
based
in
Mountain
View
California
I'm
excited
to
spend
some
time
with
you
today
talking
about
important
topics
in
Grid,
IT
security.
So
before
I
was
a
product
manager.
B
I'm,
not
so
sure,
I
understood
everything
as
well
as
I
thought
back
then,
and
in
the
meantime,
kubernetes
and
it's
related
projects
have
been
evolving
at
a
pretty
rapid
clip
in
that
vein.
I'm,
mindful
today,
that
we
have
folks
joining
us
with
a
variety
of
roles
and
experiences
and
that
there's
always
more
to
learn
in
such
a
lively
ecosystem
like
grid
of
these
and
cloud
native
I
want
to
speak
to
everyone
here
and
I
will
do
my
best
to
be
clear
in
to
avoid
shorthand
if
I
slip
up
and
do
leave
something
confusing.
B
Please
ask
a
question
so
that
everyone
else
can
benefit
from
the
clarification.
So
with
that,
let's
jump
in
today.
We'll
answer
five
questions
before
wrapping
up
with
Q&A
time.
The
first
is:
how
does
creditors
change
security?
It's
obvious
that
when
you
start
changing
around
all
the
parts
of
a
stack,
the
way
that
you
do
security
will
change
we'll
talk
through
that.
Next,
how
does
cooperation
work
in
a
Crabby
stack
or
what
about
all
the
people?
B
B
Zooming
out
a
bit,
if
you're
a
person
who
cares
about
security
and
your
organization
uses
kubernetes,
we
hope
you'll
see
some
of
the
power
and
not
just
the
new
challenges
that
it
brings.
Even
if
it
seems
like
everybody
else
is
concentrating
on
getting
things
out
the
door
and
changing
up
the
stack
for
the
heck
of
it.
We
think
there
are
ways
to
use
containers
to
get
to
an
even
better
place
than
you
were
before,
and
perhaps
you
can
bring
techniques
like
the
ones
we'll
talk
about
back
to
your
teammates.
B
It's
worth
explaining
a
bit
we're
talking
about.
First,
before
diving
in
I'll
cover
some
of
the
ways
containers
can
challenge
existing
security
programs,
but
on
the
flip
side,
the
opportunity
they
pose
to
enable
finer
grained,
more
automated
security
enforcement.
If
you're
an
already
an
expert,
please
bear
with
me
for
a
moment,
while
I
explain
a
little
bit
of
the
backstory
at
a
very
high
level,
you
can
think
of
containers
as
the
next
step,
in
evolution
from
physical
hardware
to
virtual
machines,
infrastructure
operators.
B
They
were
easy
to
commit
into
version
control
and
to
share
with
others,
and
the
containers
would,
for
the
most
part,
run
the
same
way
whether
they
were
on
a
laptop
in
dev
in
production,
because
they
had
a
defined
clean
slate
initial
file
system
in
configuration,
and
once
people
began
to
see
this
orchestrators
like
kubernetes
and
other
tools
started
to
appear
open
to
handle
scheduling,
fault,
tolerance,
storage
and
other
issues
that
creep
up
once
you
get
out
of
the
lab.
So
how
does
this
change
the
security
game?
Well?
B
A
detection
effort
has
to
recognize
that
context.
On
top
of
that,
the
landscape
is
also
shifted.
We
think
in
a
way
that
can
leave
security
as
an
afterthought.
If
dev
and
ops
on
the
cloud
account
and
operate
the
kubernetes
cluster,
for
instance,
security
doesn't
have
some
of
the
familiar
hooks
that
they
have
into
the
old
process.
So
much
of
the
infrastructure
is
software-defined
and
outside
of
the
reach
of
whatever
controls
that
might
have
been
set
up
before,
but
it's
certainly
on
all
bad
news.
B
Containers
and
communities,
especially
the
standard
api's,
can
actually
help
you
do
security
better.
They
don't
necessarily
allow
you
to
do
anything
that
wasn't
strictly
possible
before
you
could
do
many
of
the
same
things
in
different
stacks
or
in
different
ways,
and
some
people
did,
but
we
do
think
they
make
certain
practices
more
feasible.
We
would
have
had
a
lot
harder
time,
getting
the
same
level,
visibility
and,
more
importantly,
a
harder
time.
B
Iterating
on
and
testing
those
config
changes
without
a
stack
that
say
enforces
declarative
configuration
the
way
kubernetes
does
and
enables
quick
changes
without
costly
rebuild
cycles,
as
in
a
lot
of
other
realms
security
for
containers
is
a
bit
of
a
configuration
problem.
There
may
be
some
places
where
we
need
new
technology
or
new
features,
but
there
are
also
already
so
many
ways
to
configure
guardrails
limits
and
security
barriers,
and
often
the
problem
is
really
how
to
operationalize
enough
of
them
to
achieve
the
desired
level
of
security
assurance.
B
If
that
sounds
wrong,
just
a
reminder
that
any
time
somebody
makes
a
security
feature,
somebody
else
jimmies
the
door
open.
This
is
a
satellite
news
truck
which
you
can
see
in
the
Newseum
in
Washington
DC.
It
was
pretty
cutting
edge
deck
in
the
mid-80s.
It
seems
pretty
neat
and
if
you
look
at
the
display
case,
you
see
some
sort
of
machine
looks
like
it
does
some
broadcasting
it's
got
an
antenna,
it's
got
a
passcode
on
it.
B
Okay,
cool
I'm
with
you
wouldn't
want
anybody
sending
unauthorized
satellite
broadcasts
right,
but
if
he
behind
it,
somebody
decided
their
JIRA
ticket
for
secure
passcode
distribution
wouldn't
come
in
before
the
end
of
the
sprint
I
get
it
I've
been
an
engineer
for
most
of
my
career
mindset.
It's
understandable,
we've
all
had
deadlines
before,
but
it's
a
crux:
we've
also
personally
seen
that
many
companies
never
get
beyond
those
default
configs,
even
if
they're
sophisticated
in
other
ways
a.
B
Lot
of
people
are
stuck
with
the
defaults,
but
you
don't
have
to
stay
there,
so
it
is
important
that
as
a
community,
we
continue
to
innovate
and
make
more
controls
available
sure.
But
our
experiences
also
tell
us
that
many
people
could
up
their
game
with
the
knobs
they
already
have
available
to
them.
So
that's
a
fast
path.
The
value
for
most
folks
out
there,
even
without
changing
infrastructure
components,.
B
Another
promising
aspect
of
this
is
that
security
relevant
configurations
live
right
alongside
the
configs
that
say
how
the
app
operates.
So,
while
you're
developing
a
new
lockdown
profile
or
new
control,
you
can
test
it
in
the
development
or
testing
cluster.
The
same
way,
you
test
a
code
change.
You
can
even
iterate
on
security
configs
on
your
laptop,
if
you're
in
a
local
cluster
projects
like
mini
coop
or
docker
format,
make
it
easy
to
do
that
and,
of
course
running
darker
on
Linux
doesn't
need
a
special
program.
B
Next,
if
you're
also
using
microservices
design
patterns,
each
atomic
unit
of
your
app
will
be
smaller
and
can
be
locked
down
further.
Then,
when
the
pieces
of
your
app
are
talking
on
the
network,
instead
of
with
function,
calls
within
the
app
you
have
a
greater
ability
to
monitor
and
control
them,
regardless
of
the
language
or
that
frameworks
that
you
use
within
each
piece.
B
It
can
be
a
lot
easier
to
spot
anomalies
when
you
only
expect
an
entry
point
process,
and
maybe
a
few
others
which
are
not
the
case
with
with
your
own
sort
of
stack,
and
these
apps
tend
to
be
built
to
tolerate
both
replication
and
the
failures
that
one
would
expect
in
a
large
distributed
system.
So
response
can
often
go
forward
with
less
painstaking
investigation,
because
communities
can
help
you
recover
so
really
as
people
from
the
ops
and
security
communities.
B
My
stack
rocks,
colleagues
and
I
are
really
excited
to
see
the
broader
use
of
kubernetes
the
design
patterns
that
come
with
it.
We
think
the
containers
and
communities
can
really
help
a
lot
of
enterprises
up
there,
security
game
and
we
believe,
there's
a
lot
of
untapped
value
and
the
configs
that
are
already
available,
but,
of
course,
we're
excited
to
see
new
developments
throughout
the
tech
stack
as
well.
B
Let's
move
to
our
next
question:
how
does
cooperation
work
in
a
community
stack?
It's
sometimes
easy
to
talk
about
security
or
DevOps
or
workflows
or
other
ideas.
Without
remembering
that,
no
matter
what
software
we
put
in
place
or
what
automatic
triggers
we
configure,
there
are
still
people
and
people
who
are
experts
in
other
areas
might
not
yet
know
how
to
apply
their
existing
knowledge
to
a
new
stack,
that's
usually
not
because
their
community's
doubters
or
because
their
blood
I'ts
stuck
in
the
past.
B
It's
often
just
because
communities
has
come
into
the
organization
through
a
different
team
and
they
haven't
had
the
time
or
the
resources
to
learn
a
new
system.
Imagine
your
first
time
writing
a
career
IDs
deployment.
It
might
have
seemed
a
little
odd
along
those
lines.
One
of
the
concerns
our
customers
often
tell
us
about.
Is
things
move
too
fast
for
the
security
team
to
keep
up,
and
that
can
be
true
when
we'd
argue,
there's
also
an
opportunity
here.
B
Faster
changes
are
often
individually
smaller,
giving
you
a
better
chance
to
keep
up
and
faster
changes
that
roll
out
through
a
repeatable
rehearse
process
also
means
that
security
fixes
and
patches
can
be
rolled
out
faster
to
your
security
improvements.
Don't
have
to
wait
to
the
next
big
downtime.
We
find
that
teens
can
get
to
a
place
where
they
feel
confident
in
their
overall
security
posture
through
mix
of
organizational
policies,
standard
operating
procedures
and
real-time
monitoring.
B
It's
good
to.
There
are
other
good
reasons
for
teams
across
the
stack
to
make
the
investment
they
become
familiar
with
kubernetes,
compared
with
other
workflows.
That
might
have
been
a
little
bit
more
idiosyncratic
at
each
company.
Folks
who
get
over
the
kubernetes
learning
curve
end
up
with
a
more
broadly
applicable
skill
set,
regardless
of
which
team
they
find
themselves
in
and
an
organization's
adoption
of
a
more
consistent
stack
can
help
security
teams
scale
themselves
across
the
org,
even
as
the
company
scales
out
their
operations,
even
if
you're
operating
at
a
small
scale.
B
Now
investments
you
make
now
in
common
understanding,
communication
and
empathy
will
pay
a
lot
of
dividends
later
I.
Don't
think
we
talk
about
this
stuff
enough
and
we
especially
don't
invest
enough
in
empathy,
but
it's
really
important
to
understand
where
each
group
of
folks
is
coming
from
what
their
incentives
are,
what
they
want
to
see
out
of
the
container
infrastructure.
B
Sometimes
we
don't
even
say
we're
really
thinking
out
loud
like
not
just
things
are
moving
too
fast,
but
I'm
afraid
we'll
miss
something
and
on
the
other
side,
but
the
security
folks.
Here,
if
you
hear
pushback
like
this
from
Dever
ops,
I,
don't
want
the
security
feature
deployed
in
my
cluster.
It's
often
not
because
people
don't
want
to
be
secure,
but
rather
they're
afraid
that
it
will
stop
them
from
recovering
from
an
outage.
B
They
can't
do
their
job
because
of
a
security
feature
that
you're
advocating
for
so
just
like
your
application
might
have
take
some
time
to
migrate
to
containers
or
kubernetes.
So
might
people
and
org
structures?
That's
a
whole
other
talk
by
itself.
But
do
you
keep
it
in
mind
when
it
seems
like
somebody
just
doesn't
get
it?
B
I'll
shift.
Now
to
some
practices
and
mindsets
you
can
adopt
to
improve
your
security
posture
I'll
cover
infrastructure.
First,
before
moving
on
to
application
workloads,
the
line
can
be
a
little
fuzzy
and
there's
some
overlap,
but
I
think
a
division
can
be
helpful
because
infrastructure
typically
has
a
different
and
longer
life
cycle
than
each
individual
app.
B
The
videos
are
great:
the
gates
in
CNC,
F
blogs,
the
documentation
and
other
community
resources
to
keep
up
on
other
topics,
even
if
you're
just
getting
started
with
kubernetes,
it's
important
to
keep
certain
things
in
mind,
so
that
future,
you
is
happy,
but
the
pattern
into
the
present
you
established
today.
If
you're
already
running
active
old
clusters,
you
might
need
to
think
about
new
topics
or
revisiting
the
old
decisions
that
you
might
have
made
a
shortcut
on
before.
B
There's
a
lot
out
there
and
we're
only
going
to
talk
about
some
of
the
moves
common,
so
there's
good
infrastructure
habits.
First
of
all,
we
think
is
super
important
to
be
ready
to
be
upgrade.
You
may
have
to
do
this
on
short
notice,
and
you
would
have
seen
that
in
the
few
cases
recently.
So
while
the
community
is
great
at
responding
to
vulnerabilities
and
issues,
sometimes
that
upgrade
is
necessary.
B
B
The
next
one
comes
a
little
bit
from
the
field
too.
So
keep
the
abstractions
tight.
You
don't
want
leaky,
abstractions
and
really
what
this
means
is
when
you're
setting
up
your
infrastructure,
it's
really
best.
If
you
can
minimize
interactions
with
other
levels
of
the
stack,
so
if
your
application
doesn't
need
to
know
where
it's
running,
that's
the
best
case,
some
folks
that
we
speak
an
diffusing
host
notes.
As
an
example,
we
went
to
one
environment
where
the
host
name
and
some
other
host
paths
remotes.
B
Those
sorts
of
things
can
make
it
harder
to
make
your
app
portable
can
make
it
harder
to
make
changes
like
like
upgrades
and
other
other
configuration
changes
now
in
the
infrastructure
layer
to
API
access
controls
is
a
topic
that
fits
in
here.
So
the
communities
API
has
has
what's
called
role,
based
access
control,
in
contrast
to
the
attribute
based
access
control
that
was
introduced
earlier,
and
it's
a
really
powerful
feature
for
keeping
lock
down
on
who
can
do
what
in
the
grid
IDs
API?
As
we
mentioned,
the
crew
native
API,
is
super
powerful.
B
It
lets
you
deploy.
New
workloads
set
policies.
Can
figure
out
how
the
cluster
runs
so
that
API
access
control
is
super
very
important
and
what
we
often
see
is
a
lot
of
folks
getting
cluster
admin,
which
is
a
sort
of
global
administrator
role,
especially
early
on
in
a
cluster,
it's
life
cycle
or
in
a
kubernetes
adoption
cycle.
So
it's
it's
really
time
well-spent
to
think
carefully
about
how
you
will
plan
for
user
and
group
access.
B
That
can
be
really
important
because
the
API
access
control
determines
what
can
run
and
also
who
can,
for
its
instance,
for
instance,
exact
into
containers
so
beyond
infrastructure.
Let's
talk
about
applications,
what
you
can
do
to
improve
the
security
of
your
applications
from
a
sort
of
workflow
and
general
practices
perspective.
B
So
many
of
those
here
may
be
familiar
with
the
basic
structure
of
a
create,
a
staffs,
best
justification,
but
first,
let's
zoom
out
and
look
what
it
tells
us
at
a
high
level
and
then
zoom
back
in
and
look
at
some
of
the
fields
you
might
not
have
encountered
before.
So
here's
just
a
simplified,
a
PMO.
This
is
a
deployment
and
I've
alighted
some
of
the
fields
just
because
they
don't
add
much
value
here
and
it's
a
small
slide.
B
We
find
it's
really
productive
to
focus
on
the
deployment
the
stateful
set
or
some
equivalent
resource
versus
the
container
of
the
pod,
because
this
is
the
place
that
you
have
basically
all
the
context.
You'll
ever
get
it's
the
resource
that
most
people
interact
with.
So
that's
what
your
developers
and
your
Ops
people
are
going
to
be
looking
at,
especially
when
compared
with
a
single
container,
which
is
more
of
an
owned
resource
than
a
top-level
resource.
B
There's
a
lot
to
do
in
each
other
area,
but
the
deployments
a
really
great
place
to
anchor
your
worldview.
So,
let's
start
by
reminding
ourselves
if
all
the
data
found
in
a
single
spec
for
a
simple
application,
I've
added
some
features
that
may
not
be
necessary
in
every
application,
just
as
an
example,
this
is
so.
This
is
ultimately
a
pretty
standard.
Cabrini's
deployment
spec
with
some
of
the
details,
collapsed
so
we're
at
the
top.
B
You
see
some
operational
metadata
so
in
in
our
example,
we've
got
some
labels
that
say
sort
of
what
the
application
is
then
also
some
annotations
that
help
us
understand.
What's
going
on
with
it,
maybe
who
owns
it,
which
team
and
then
how
to
contact
them.
In
the
case
of
an
issue,
the
annotations
add
things
sort
of
about
the
app
and
we
find
a
lot
of
people
can
productively
use
that
to
help
other
people
understand
what
the
application
is.
B
Next,
you
start
seeing
things
about
say
what
the
application
is,
what
code
is
going
to
run
when
we,
when
we
get
this
started,
and
the
cool
thing
about
images
too,
is
that
while
they
have
references
that
are
pretty
like
this,
they
also
have
cryptographic
digests.
So
you
know
exactly
the
contents
of
the
application
that
will
be
your
the
container
that
will
start
the
filesystem
and
the
initial
configuration
as
we
can
see
which
sort
of
volumes
it
can
access.
So
this
can
be
storage
or
secrets
and
other
types
of
things.
B
B
Now.
That's
a
lot
of
application.
That's
a
lot
of
information
in
a
fair
bit
of
it
might
have
previously
been
hidden
inside
of
a
VM
image
and
some
supervisor
config
file
or
inspects
across
the
mix
of
other
systems
with
communities.
On
the
other
hand,
all
this
content
will
usually
be
credited
and
gets
in
some
way,
or
some
other
version
control
system
and
kept
in
the
same
place
as
or
at
least
nearby
the
application
code
and
critically
we
can
get
to
all
of
this
context
later
once
the
application
is
running.
B
So
we
know
not
only
exactly
what
the
image
was,
but
maybe
where
it
is
which
team
or
business
unit
was
running
it
any
annotations
and
labels
that
operations
sort
of
folks
added
to
help
explain
the
application,
the
privileges
that
it
has,
including
access
the
host
to
the
kubernetes
api
access,
the
secrets,
storage,
things
like
that
networking
configuration,
including
policies,
exposure
and
other
networking
configurations
and
the
behavior.
We
can
find
all
of
this
together
anchored
around
the
kubernetes
deployment.
B
Really
it's
not
rocks.
We
think
one
of
the
unsung
heroes
of
Trinity's
is
the
api
surface.
It
seems
kind
of
obvious.
You
know
the
tools
got
to
have
an
API,
so
I
think
a
lot
of
people
sort
of
take
it
for
granted,
but
the
very
idea
of
having
standard
API
s
and
standard
concepts
for
access
to
all
these
things.
Secret
storage
network
serving
exposure,
ingress
and
more
is
super
powerful
and
that
power
can
really
change
the
game
for
security.
Now,
if
your
experience
with
kubernetes,
you
might
have
spotted
some
things
in
that.
B
Will
that
look
off
to
you
great?
It
sounds
like
you
have
a
good
eye
for
style.
As
with
writing
your
programming,
it
can
be
useful
to
have
a
style
guide
that
says
how
your
organization
will
use
the
basic
tools,
the
primitives
that
you
have
available
to
you.
There
may
be
more
than
one
good
way
to
set
things
up,
but
if
you've
ever
walked
in
through
a
code
base
or
a
written
document
for
each
person
or
each
author
has
embraced
their
own
style.
B
You
know
it
can
be
really
difficult
to
understand
how
things
work
or
interact,
there's
real
power
and
consistency
along
those
lines.
Many
of
our
customers
have
adopted
basic
labeling
and
annotation
schemes.
As
I
mentioned,
the
responsible
team
is
a
common
annotation
and
some
customers
require
that
it
be
set
before
things
can
be
deployed.
You
might
find
other
metadata
relevant
in
your
organization.
Maybe
a
chat
room
handle
a
phone
number
or
department
name.
B
Consistent
minute
that
I
can
really
help,
especially
in
the
response
phase,
when
you're
trying
to
understand.
What's
going
on,
you
need
to
ask
someone
a
question.
Remember
people
are
still
in
the
loop
in
the
application
and
workload
realm.
Knowing
your
images
is
actually
also
very
important.
There
are
a
variety
of
techniques
you
can
apply
here
and
only
briefly
cover
them,
but
deciding
on
a
minimal
base
image
can
be
extremely
powerful.
If
you
start
with
a
rather
large
image,
we
see
sometimes
images
with
700
packages
installed.
B
B
Similarly,
metadata
applies
here
to
image.
Labels
can
be
very
powerful
to
help
people
understand
what
an
artifact,
because
they
can
pull
that
later
from
the
registry
and
understand
what
the
what
the
artifact
is
sort
of
on
the
on
the
workflow
side
of
things
in
the
standard
procedure
side,
if
you're
just
starting
out,
establish
the
grip
practices.
B
Now
you
won't
want
to
do
it
later
and
if
you're
already
running,
maybe
consider
which
sort
of
things
you
can
begin
opting
into
really
and
the
sort
of
design
phase,
it's
really
important
to
plan
for
replicas
to
be
killed
in
the
case
of
a
compromise.
So
we
find
the
security
response
is
really
aided
when
the
security
team
can
can
decide
that
this
application
is
doing
something
that
is,
that
is
not
okay,
and
there
are
some
applications
that
they
have
sort
of
preclearance
to
respond
to
in
automated
ways.
B
Now
we
talked
about
secure
practices.
So
how
should
we
enforce
them?
Well,
there
are
a
couple
of
options
and
they
include
using
pod
security
policies
or
other
built-in
admission
controllers,
using
a
custom
and
mission
controllers,
and
the
other
approach
is
including,
like
reactive
monitoring
and,
for
instance,
what
you
might
get
in
a
security
platform
or
in
some
open-source
tooling.
That
would
use
the
communities
API.
But
remember
these
your
experience
and
the
people
you
might
decide
to
use
a
mix
of
these
approaches.
B
For
instance,
we
found
that
admission
control,
including
pod
security
policies,
is
best
limited
to
either
larger
risks
that
require
a
conversation
before
you'd
be
comfortable
using
them
and
wouldn't
be
used
normally
like
the
privilege
mode,
for
instance,
or
things
that
individual
developers
and
operators
can
always
fix
like
using
the
latest
AG,
it's
always
possible
to
find
a
digest
or
find
an
alternative
tag
on
the
admission
control
front.
I'll
just
put
a
plug
in
one
of
my
colleagues:
Trinity's
blog
entry.
B
So
on
the
user
experience
front,
remember,
there's
nothing
that
will
get
a
security
control,
throw
not
faster
than
causing
an
outage
or
preventing
the
response
to
one.
So
while
it
might
be
tempting
to
say,
block
everything
that
has
a
specific
component
or
violates
a
certain
best
practice,
it's
really
important
to
think
about
what
you
really
want
to
put
your
put
on
the
line
here.
More
ambiguous
images,
issues
like
image,
components
or
lower
severity.
Vulnerabilities
can
often
be
better
handled
by
applying
a
risk
management
approach.
B
B
B
So
there's
a
variety
of
configurations,
we'll
discuss
here.
I'll
first
take
the
first
thing,
so
a
read-only
root
filesystem.
This
is
one
that
we
think
doesn't
get
enough
attention.
It's
a
single
boolean
field
that
you
can
enable
in
your
community
aspects
that
causes
the
slash
file
system
to
get
mounted
read-only,
and
this
is
really
powerful,
because
a
lot
of
ever
series
when,
when
exploiting
say
command
injection
bugs
will
assume
the
certain
paths
are
writable
like
slash
temp.
B
Another
is
Linux
capabilities,
so
there's
a
default
set
of
capabilities,
most
containers
launch
with
and
some
of
them
don't
need
them.
So
if
your
application
knows
that
or
if
you
know
that
your
application
doesn't
need
some
of
them
or
if
you
can
find
out
using
runtime
monitoring,
you
can
reduce
the
capability
set.
B
One
of
my
colleagues
and
I
spoke
at
the
besides
San
Francisco
security
conference.
There's
a
video
online
about
this
recently
using
runtime
monitoring
to
understand
which,
from
the
capabilities
you
might
be
able
to
drop
and
finally
network
policies,
they'll
be
included
in
this,
and
this
walkthrough
network
policies
are
a
really
powerful
feature
of
kubernetes.
That's
been
around
for
I
think
at
least
eighteen
months.
B
We
find
that
a
lot
of
folks
haven't
picked
them
up
because
either
they
didn't
start
with
network
policies,
so
they
haven't
gotten
in
the
habit
and
now
it's
too
big
a
problem
to
migrate
or
because
they
just
find
them
off
the
beaten
track
and
haven't,
haven't
taken
the
time
to
learn
them
and
really
understand
how
they
work.
It
can
be
complicated,
so
I
again
back
to
empathy.
I
really
understand
this
I
remember
when
I
first
learned.
So
let's
talk
about
those
three
first
and
come
back
to
the
glass.
B
So,
in
order
to
avoid
tempting
fate,
I've
run
this
demo
in
advance
and
here's
how
we
can
stop
the
struts
to
exploit
using
some
of
the
controls
that
I
just
mentioned.
So
the
setup
here
is
I
deployed
a
real
container
in
a
real
quick
release.
Cluster
here
you
can
see
sort
of
the
log
of
it
creating
a
deployment
in
pods
that
container
had
a
head
of
exploit
from
2017
one
of
the
famous
struts
command
ejections.
B
So
we
deployed
a
vulnerable
container
with
a
readwrite
root,
filesystem,
no
special
lockdown,
and
then
we
went
to
exploit
using
a
very,
very
long
curl
an
HTTP
request
with
an
injection
crafted
injection
that
will
download
a
tarball
from
github
from
a
crypto
minor
release
web
site
on
target
and
start
running,
and
you
can
see
that
in
the
official
one
herbal
deployment
we
can
use
the
command
injection
vulnerability
to
to
run
that
through
a
shell.
So
Java
is
supposed
to
be
running.
That's
what
the
app
is.
B
But
now
we
also
have
process
running
health,
minor
D,
which
is
a
crypto
minor
and
going
back
to
the
b-side
stock.
I
mentioned
it's
possible
to
to
monitor
your
container
and
monitor
file
rights,
to
understand
whether
you
can
mark
certain
paths,
read,
write
and
go:
read
it
only
for
the
overall
path
for
the
overall
file
system.
B
So,
as
an
example,
we
found
that
with
this
container,
it
does
need
to
write
to
use
your
local
Tomcat
upon
startup,
but
it
doesn't
seem
to
write
anywhere
else,
which
makes
it
possible
to
write
a
read-only
file
system
and
declare
user
local
Tomcat
as
a
volume
in
the
doctor
file.
There
are,
you
know
at
least
two
ways
that
you
can
can
accomplish
this.
We
typically
like
the
declare
volume
in
the
image,
because
the
prisoner
it
can
preserve
existing
content,
but
you
can
also
imagine
be
during
Corinna
DS.
B
It's
a
type
of
volume
that
that
exists
on
the
host,
a
sort
of
scratch
space,
but
doesn't
survive
after
the
pod
dies.
Our
three
scheduled
so
after
updating
to
declare
a
volume
in
that
image
and
upgrading
the
deployment
just
use
the
new
image
within
volume
and
changing
the
config
to
specify
a
read-only
root
filesystem.
B
We
do
the
same
thing
setup,
a
coop,
Codel
port
forward
and
then
try
to
use
the
same,
crafted
HTTP
request
and
when
the
exploit
script,
attempts
to
download
the
miner
GPZ
to
introduce
new
software
into
the
into
the
container
it
errors
and
says
there
was
a
read-only
root
files
or
a
read-only
file
system.
Here,
I'm
not
allowed
to
modify
this
path
and
just
lines
you
can
see.
Then
let
me
exact
to
find
the
commands
that
are
running,
that
it's
just
rapid,
the
miner
didn't
get
to
unpack
and
therefore
didn't
get
to
run
either.
B
This
is
just
an
example
of
a
visualization
of
these
policies.
We
find
that
you
know
there's
a
lot
of
power
there,
but
configuring
firewalls
is
never
easy
and
while
Communities
gives
the
user
to
the
right
abstraction
here,
you
could
just
specify
which
pods
can
talk
to
which
pods
none
of
which
ports
ingress
and
egress.
It
could
be
a
little
bit
complicated
to
understand
the
full
effective
graph
of
what's
possible.
B
So
just
in
this
example,
we
see
some
active
connections
obtained
through
bunch
I'm
monitoring
those
are
the
solid
lines
and
then
there
are
some
extra
connections
that
are
allowed
using
the
dashed
lines,
and
we
find
that
most
folks
either
don't
have
any
network
policies
or
have
some
over
broad
ones.
So
it
can
be
really
a
key
to
sort
of
never
segmentation
to
check
out
what
never
policies
are.
There's
some
community
resources,
including
basically
recipes
for
how
you
can
deploy
different
policies
or
there
are
products
that
can
help.
B
You
understand
those
as
well,
but
we've
never
read
only
root
filesystem
linux
capabilities
and
network
policies,
basically
preventing
modifications
to
the
container
file
system
by
preventing
any
command
from
from
executing
certain
privileged
actions
and
applying
never
sick
when
tation
and
together,
those
really
do
eliminate
a
fair
number
of
the
things
that
opportunistic
adversaries
will
try
to
do.
We
found
with
some
you
know,
honey-nut
research,
that
people
are
kind
of
lazy
and
when
they
tried
to
inject
code,
they'll
often
assume
that
slash
temp
is
is
available.
B
B
So,
let's
move
on
to
the
other
controls,
so
host
notes,
like
I
mentioned
before
in
the
infrastructure
section,
the
more
you
can
avoid,
knowing
anything
about
the
hosts,
the
better.
It's
also
considered
some
of
the
your
flexibility
to
move
into
serverless
or
node
list
platforms
in
the
future,
where
you
wouldn't
have
the
same
kind
of
footnotes,
and
sometimes
that
means
application
changes.
Sometimes
applications
are
built
to
understand
something
about
where
they're
running
you
need
somebody
unique
identifier
for
the
hosts
or
something
like
that.
B
Next,
we
can
talk
about
service
account
autumn,
outing.
So
again,
a
callback
from
from
the.
If
structure,
hardening
section
api
access
control
is
really
critical
for
users
and
groups.
Definitely
so
you
don't
want
to
have
too
many
users
who
are
able
to
say
modify
production,
but
also
applications
can
have
access
to
the
communities
api,
and
if
you
don't
need
your
application
to
speak
to
the
communities
api,
you
can
disable
auto
mounts
on
the
service
account
itself
or
in
the
pod
stack
so
for
each
pod
you
can
say
I
don't
actually
need
a
service
account.
B
Please
don't
give
me
one
and
that's
found
in
the
security
context,
if
I
recall
correctly:
next,
the
environment,
this
is
kind
of
a
container
specific
thing,
brushes
kubernetes,
but
the
environment
is
not
a
safe
place
to
store
things
if
you
secret
things,
at
least
so.
If
you
end
up
using
the
environment
for
sensitive
things,
maybe
connection
strings
or
API
tokens.
Please
don't
commit.
These
has
great
secret
support
and
you
can
mount
things
in
as
files
which,
which
makes
it
a
bit
harder
for
for
others
to
observe
them.
B
It's
important
to
remember,
too,
that
there
there
are
new
wall
containers
can
help
you
do
security
better.
There
are
also
new
infrastructure
components,
so
things
like
the
couplet
API
server
and
in
some
configurations
those
can
leak
things
like
the
environment
variables,
which
means
that
you'd
be
better
off,
not
putting
secret
things
in
those
and,
finally,
one
that
maybe
doesn't
come
up
in
in
security
circles
as
much
resource
requirements
that
maybe
it
should
because
availability
as
part
of
the
CIA
or
AIC
try
it
the
confidentiality
integrity,
availability
triad.
B
Now,
if
someone
can
exploit
an
issue
in
your
in
your
application
and
cause
sort
of
a
rolling
outage
in
your
application,
that's
not
good
and
communities.
Those
have
the
ability
to
specify
both
requests,
which
you
should
use
all
of
our
customers
at
scale
basically
require
resource
requests,
at
least,
but
limits
are
also
very
powerful
for
CPUs.
You
can
specify
that
this
application
should
not
take
more
than
a
certain
amount
of
CPU
and
that's
CPU
will
then
be
it'll,
be
nice
to
down.
So
it
will
never
exceed
that
that
limit.
B
If,
if,
if
needed,
for
memory,
it's
a
little
bit
more
blunt
force.
If
you
exceed
your
memory
limit
you'll
just
get
your
container
the
process
killed.
So
we
tend
to
see
those
set
to
rather
high
levels
that
are
maybe
a
large
portion
of
the
notes
available
memory
so
that
a
true,
runaway
train
will
get
stopped,
but
no
more
application
operations
won't
be
impacted.
B
Those
are
some
of
the
main
configurations
that
we
think
people
can
adopt.
I.
Think
especially
we
don't
agree.
File
system
is
something
that
many
apps
can
do.
It's
a
relatively
easy
configuration
change.
I
might
be
able
to
head
back
to
if
you
may
recall
at
least
the
earlier
slide,
where
we
added
certain
configurations.
It's
just
a
single
boolean
inside
the
security
context.
It's
rather
easy
to
opt
into,
and
then
in
most
cases
you
can
either
deploy
a
volume
or
an
empty
der
to
handle
it
to
handle
any
writable
file
system
needs.
B
Now,
with
all
these
configurations,
it
could
be
done.
These
gives
you
advantages,
because
you
can.
You
can
test
them
like
I
mentioned,
so
they
get
the
best
ones
of
these
are
committed,
as
as
configurations
in
your
deployment,
yeah
mole
or
in
other
in
other
places,
and
you
can
test
them
on
your
laptop
test
them
in
dev
in
QA,
before
you
roll
them
out
to
production.
So
we
think
people
can
really
confidently
explore
these.
B
For
instance,
when
we
were
getting
to
read-only
root
filesystem
in
our
application,
we
would
just
push
it
to
CI
and
it's
the
iPass
you're
good
to
go.
Of
course
we
do
the
manual
QA
testing
as
well,
but
we
can
move
forward
with
with
pretty
good
assurance.
It's
important
to
note
also
for
in
some
of
these,
like
network
policies
that
you
do
have
to
have
some
infrastructure
pieces
in
play
they're
in
place
before
you
can
use
them.
B
For
instance,
you
may
need
to
opt
into
a
network
driver
that
supports
network
policies
and,
depending
on
your
cloud
provider
or
the
way
that
you
manage
your
hosts,
you
may
need
to
take
some
action
there.
So
at
this
point
we've
covered
the
main
topics
here.
If
there
are
questions
you
have,
they
believe
they're
being
bought
or
you
didn't
sue
if
you
think
of
one
later
feel
free
to
email.
Me
I'm
just
see
the
letter
CS
that
rocks
calm
or
at
Connor
Gilbert
on
Twitter,
and
then
there's
also
a
place
for
more
resources
on
the
web.
A
B
Sure
so,
I
think
of
them
really
as
to
kind
of
separate
but
related
topics.
So
your
are
back
will
help
you
prevent
unauthorized
folks
from
modifying,
create
ease
resources
or
control
how
people
can
access
the
resources
that
are
already
deployed
admission
control.
We
typically
I
mean
there's
some
built-in
admission
controllers
that
help
establish
certain
things
like
namespaces
have
to
be
created.
A
B
That's
an
interesting
question,
so
I
think
I
would
actually
recommend
trying
you're
in
our
policies.
Basically
as
many
places
as
you
can,
and
perhaps
in
dev,
you
might
add
another
Network
policy,
because
in
general
network
policies
once
you've
selected
a
pod,
no
no
traffic
is
restricted,
so
you
can
add
another
policy
that
allows
different
access.
B
I
tend
to
prefer
keeping
the
number
policies,
basically
right
next
to
the
deployments
that
they
control
so
often
it's
it's
very
productive
to
have
ingress
rules
for
which
service
niku
can
be
its
clients
and
that
lends
itself
to
being
stored
right
next
to
the
deployment.
Oh,
this
tape
will
set
that
sort
of
app
spec.
That
could
be
a
great
place
to
put
them
other
people
like
to
manage
them
centrally
other
that
can
have
some
some
more
issues,
just
around
keeping
everything
in
sync
and
then
just
sort
of
nuts
and
bolts.
B
A
A
B
So
those
are
some
important
security
controls,
the
dashboard,
if
you
don't
need
it,
it's
best
to
just
turn
it
off.
Certain
cloud
providers
will
default
that
way.
Certain
Club,
shredders
and
other
systems
will
be
fault
to
deploying
the
dashboard
and
also
the
metadata
server.
For
those
who
don't
know
is
a
cloud
provider
service
and
that
can
be
sometimes
accessed
from
your
applications
if,
for
instance,
your
application
has
a
server
side
request
for
jury
issue,
we
saw
this
with
Shopify
bug,
bounty
and
I
always
like
to
give
credit
to
them
for
publishing
this
bug
bounty.
B
So
everyone
could
learn
about
it.
So
how
do
you
verify
that
the
clusters
is
set
up
correctly?
It's
going
to
be
some
mix
of
looking
at
resources
like
network
policies
and
other
other
other
configurations
that
sort
of
exists
in
the
chordates
api
and
then
another
great
place
to
start
is
with
like
the
CSC.
Is
communities
benchmark,
so
the
Center
for
net
security
publishes
certain
guidance
about
the
important
controls
that
it's
are
set
on
the
API
server,
how
you
actually
assess
that
will
differ
based
on
how
you're
running
forged
IDs.
B
So
if
you're
running
in
a
managed
service
like
Google
compute
engine
you'll
use
the
cloud
provider
API
is
to
understand
key
features
that
are
turned
on
or
off.
Well,
if
you're
operating
your
own
cluster,
you
might
have
a
config
file
that
lists
more
of
these
or
you
could
just
look
at
the
master
and
look
at
the
command-line
arguments.
The
API
server,
so
the
mechanics
will
differ
to
space
on
how
you
deployed.
B
Question
it's
a
bit
of
an
interesting
so
so
we
did
a
bit
of
a
talk
on
this
using
runtime
monitoring
to
help
generate
more
secure
configs
at
besides
I
think
we
can
try
to
maybe
get
the
the
link
on
to
that
landing.
Page
I'm
signing
some
people
up
for
work,
so
maybe
wait
a
little
while
and
you'll
see
it
or
search
on
youtube
for
besides
San
Francisco,
that's
2019,
so
the
technique
we
used
there
was
was
instrumenting.
The
kernels
cap
capable
function
which
is
used
to
check
whether
capabilities
are
present.
B
That's
one
way.
Another
is
to
just
sort
of
know
what
your
application
is
doing
and
guessing
check
it's
a
little
unsatisfying
as
an
answer.
But
if,
for
instance,
you
know
there
are
certain
ones
that
are
more
obvious.
So
if
you
know
that
you're
not
sending
raw
packets,
you
can
drop
cap
net
raw,
just
sort
it
out
of
the
box.
As
you
know,
you
don't
do
file
operations.
You
can
drop
a
few
of
those
file
ready
capabilities,
so
just
kind
of
an
open
area,
but
certainly
like
never
all-
is
a
good
one
to
drop.
A
B
B
When
we
come
to
some
place
and
see
that
everything
is
in
default,
it
makes
us
a
little
sad
because
it's
hard
to
understand
what
the
application
is
and
we
empathize
with
the
folks
you're
gonna,
have
to
respond
and
understand
which
of
the
50
services
here
belong
to
which
sort
of
team
so
using
namespace
as
a
first
go
is
important
know
for
resource
quotas,
the
at
the
namespace
level.
We
tend
not
to
see
as
much
value
there,
at
least
from
a
security
perspective.
B
That
seems
more
like
a
budgeting
and
sort
of
resource
planning
issue
at
the
main
space
level.
The
place
where
I
think
it's
it's
most
important
from
a
security
and
availability
standpoint
is
more
about
individual
deployments
and
not
being
able
to
be
runaway
trains
that
sort
of
cascading
the
cluster.
So
especially
memory
limits.
That's
on
a
each
workload.
I
think
those
are
strictly
more
important
than
namespace
quotas.
A
B
A
good
practice,
so
it's
best
not
to
run
as
root
in
the
container,
because
many
people,
most
don't
remap
user
name
spaces
between
the
containers,
the
container
engine
in
the
host.
So
it
can
be
really
productive
to
to
use
a
non
where
user.
If
you're
going
to
use
a
persistent
storage,
it
is
really
important
to
have
a
UID
or
a
GID
set
up
in
advance.
So
you
can
make
sure
that
the
storage
has
access
to
that.
That
is
a
good
practice.
A
B
B
Therefore,
the
CNI
providers
that
know
that
about
network
policies,
they'll
read
the
number
policies
from
the
API
and
enforce
them,
so
you'd,
be
configuring
them
via
Network
policy
animals
and,
if
you're,
deciding
sort
of
your
infrastructures
back
it's
important
to
have
a
provider
that
supports
number
policies.
Most
of
the
main
ones
do,
but
you
may
have
to
opt
in,
and
your
provider
or
management.
B
Didn't
mean
to
imply
that
you
could
it's
it's
best
practice
to
run
it
in
on
your
user
and
then
you
would
stay
on
root.
The
the
issue
that
I
was
the
measure
if
the
response
to
an
earlier
answer,
but
the
issue
I
was
pointing
to
is,
if
you
do
run
as
root
by
default,
which
is
the
default,
then
then
you're
in
you
could
be
in
trouble.
B
B
Okay,
yeah
I,
don't
have
a
number
for
you,
but
the
size
of
the
docker
image
certainly
does
sort
of
point
to
things.
That
would
be
problematic.
So
if
you
have
a
really
really
large
image,
chances
are
you've,
got
lots
of
components
and
lots
of
components
means
lots
of
stuff
for
adversaries
to
take
advantage
of,
but
also
potential
for
vulnerabilities,
so
I
mean
I've
rule
of
thumb.
B
You
know
if
you're,
if
you're
in
the
you
know,
tens
of
megabytes
range
you're,
probably
pretty
good,
if
you're
in
hundreds,
you
may
be
fine,
but
there's
probably
room
for
improvement
if
you're
above
you
know
a
gigabyte
or
so
that's
when
I
would
start
to
be
really
wondering
what's
going
on
in
this
image.
Usually
that
would
point
to
something
maybe
starting
too
much
data
in
the
volume
or
too
many
components
so
and
also
could
impair
your
availability.
If
things
are
going
to,
you
know,
reschedule
pods,
you
don't
want
to
have
to
wait
for
it.
B
So
I
think
one
of
the
cool
things
about
containers
and
about
microphone
patterns
is
that
you
can
tailor
your
policies
pretty
well
a
lot
of
applications,
depending
on
sort
of
what
you're
doing
in
the
container
a
lot
of
applications
that
you're
running
it's
it's.
It's
likely
that
you
don't
need
much
in
the
way
of
hosts
access
or
even
for
some
storage,
some
plans
if
you're
running
API
servers
or
caches
or
that
sort
of
thing
it's
likely,
you
don't
need
much
elevated
access
at
all,
so
read-only
Ruta
fast.
B
B
There
any
embedded
security
I
think
I'll
take.
The
question
is
asking
like:
does
a
container
healthy?
You
contain
things.
Maybe,
and
the
answer
is
yes,
there
are
certain,
you
know
it
does
help
to
run
things
in
a
container
containers.
Aren't
solely
for
containing.
You
can
think
of
the
visual
metaphor.
Is
a
shipping
container
maybe
use
more
productive
than
a
like
locked
box,
but
just
the
fact
that
the
container
amounts
a
specific
file
system
and
the
fact
that
you
can
configure
a
lot
of
controls
like
the
read-only
rediff?
Is
the
draft
capabilities,
a
different,
our
identity?
A
B
A
great
question
so-
and
it
speaks
a
lot
to
the
way
that
we've
designed
our
products,
which
is
to
use
the
Carina
it
uses,
features
that
we
can
that
we
can
as
much
as
possible.
The
benefit
of
that
is
is
that
you've
got
portable,
robust
and
usually
scalable
controls.
So,
for
instance,
if
you
work
on
getting
a
network,
false
you
set
up,
it'll
apply
basically
anytime
anywhere
that
you
have
a
cni
provider
that
knows
about
policies.
B
A
Thank
you
so
much
funner
for
going
through
all
those
questions
quickly,
so
we
could
get
to
all
of
them.
So
that's
all
the
time
we
have
today.
Thank
you.
Everybody
who
has
joined
us
and
for
all
of
those
great
questions
that
were
asked.
The
webinar,
recording
and
slides
will
be
online
within
24
hours
and
we
look
forward
to
seeing
you
all
at
a
future.
Cmc
weather.