►
Description
The world of Kubernetes security can seem a bit daunting when you're getting started, with a load of areas to look at and a panoply of tools that can be used.
From authentication, to authorization, workload security and network policies, there's a lot to think about. This talk will help you work out where to start, give you some ideas on what's likely to be important for your cluster and talk about some of the key open source projects you can use to keep your environments secure.
B
How's
it
going
yeah.
Let
me
just
get
my
slides
up
it
slides,
okay,
awesome.
Hopefully
everyone
can
see
the
slides
yeah,
so
the
the
goal
of
this
talk.
The
reason
I
ended
up
giving
this
talk
was
every
time
I
do
a
piece
of
I
talk
about
kubernetes
security
or
container
security.
One
of
the
questions
I
always
get
asked
is:
what's
the
one
thing
I
can
do
for
container
security
or
for
kubernetes
security?
B
I
think
that's
quite
kind
of
common
theme
because
a
lot
of
companies,
you
know
they're
getting
started
with
containers,
they're
getting
started
with
kubernetes
and
they
don't
necessarily
have
a
lot
of
time
to
think
about
the
security
side
of
things.
So
where
do
you
start?
And
so
that's
the
goal
of
this
talk?
What
I
want
to
do
is
go
through
some
ideas
about
how
you
can
think
about
security.
B
B
So
before
we
get
started,
just
very
brief
about
me,
I
have
I
my
background
is
information
and
I
t
security
working
in
financial
services
consulting
a
number
of
places.
Last
ten
years
I've
been
a
pen,
tester,
so
kind
of
basically
breaking
into
systems
and
the
last
five
of
those
most
of
those
systems
were
docker-based
or
kubernetes-based
lots
of
container
work.
B
B
I
think
we
sent
our
rain
down
south
this
year,
because
usually
it
rains
here
pretty
much
all
summer,
but
actually
we've
had
lots
of
nice
days
so
nice
place
to
visit.
If
you
get
a
chance,
hey,
let's
get
started
on
the
talk.
The
first
thing
that
I
wanted
to
talk
about,
or
the
first
thing
I
think
you
need
to
think
about
when
you
are
getting
started
with
kubernetes
security-
is
how
much
resources
do
you
have
to
do
this
right?
B
Do
you
have
like,
like
this
you've
got
like
a
squad
of
people
who
you
can
dedicate
to
doing
all
the
different
activities
you
might
want
to
do?
You
might
want
to
do
image
management
container
security?
You
might
want
to
do
service
mesh
security.
You
might
want
to
do
hardening
in
an
ideal
world.
You
would
have
resources
that
looked
like
this.
You'd
have
lots
of
people
to
do
all
the
activities
you
need,
but
let's
be
realistic
for
most
people,
they've
got
a
lot
of
work
on.
B
They've
got
a
lot
of
different
things
to
work
with
think
about,
and
the
primary
focus
is
going
to
be
making
things
work
right.
It's
going
to
be
getting
your
cluster
working,
getting
your
applications
working
and
keeping
them
working.
So
when
it
comes
to
security,
your
resources
probably
look
a
bit
more
like
this
right.
You
may
have
if
you're
lucky
a
full
dedicated
person.
You
may
just
have
a
bit
of
someone
else's
time.
You
know
when
they've
got
something
running.
They
may
have
a
bit
of
time
to
work
on
hardening.
B
It
may
be
something
people
have
to
work
around
as
part
of
their
other
responsibilities,
and
this
is
why
it's
really
important
to
think
about
where
you
get
started
and
targeting
your
resources.
Well,
because
if
you
haven't
got
a
lot
of
people
to
spend,
you
don't
want
to
spend
that
little
time
that
you've
got
doing
things
that
don't
really
improve
matters.
B
So
how
do
you
go
about
doing
this?
This
is
what
I
want
to
talk
about.
Is
how
can
you?
How
can
you
actually
do
that?
How
can
you
think
about
this
try
and
make
sure
you're
targeting
those
limited
resources
in
the
right
place?
So
here's
how
I
would
do
it
or
how
I
did
it
first
thing
you
need
to
think
about.
Is
your
threat
model
now
threat
modeling
is,
you
know,
there's
whole
books
written
about
remodeling,
but
but
really
when
you're
getting
started,
you
can
think
about
it
like
this.
B
So
you
can
just
think
of
which
of
these
three
apply
to
you,
the
first
one
is:
if
your
clusters
are
on
the
internet
or
the
applications
that
they
host
are
on
the
internet,
then
you
need
to
worry
about
internet-based
attackers.
There
are
people
on
the
internet
scanning
around
the
internet,
looking
for
vulnerable
systems
all
the
time
using
automated
scans
or
even
or
manual
attacks.
B
If
you're
on
the
internet,
you
need
to
worry
about
them.
There
was
some
research
done
by
our
we've
got
kind
of
a
threat.
Research
team
called
nautilus
and
their
latest
statistics
were
that
from
the
time
a
vulnerable
system
and
their
case,
a
docker
daemon
was
put
on
the
internet
to
the
median
time
to
attack
is
50
minutes
so
less
than
an
hour.
So
if
you
put
a
vulnerable
system
on
the
internet,
then
you
know
you
have
about
an
hour
before
it's
likely
that
someone's
going
to
find
it
and
try
and
compromise
it.
B
So
that's
the
first
threat
model
and
most
clusters
probably
have
to
worry
about
that.
The
second
one
is
compromised
containers
right
if
you've
got
say
10
or
20
applications
running
in
a
cluster.
Statistically,
it's
likely
one,
that's
gonna
have
a
vulnerability
right,
applications
have
vulnerabilities
and
it
can
get
exploited
and
when
it
gets
exploited,
your
attacker
is
going
to
land
in
a
container
inside
the
cluster.
B
So
if
you've
got
kind
of
set
up,
you
need
to
worry
about
the
sort
of
things
you
would
do
to
protect
against
someone
once
they've
landed
in
a
container
from
going
around
and
trying
to
compromise
the
cluster.
The
third
one
is:
is
compromised
user
credentials.
So
if
you've
got
a
lot
of
users
in
your
system
or
if
you
know
some
clusters
are
even
you
know
worried
about
like
users
not
being
able
to
get
too
much
access,
then
you
might
need
to
think
about
that
as
well.
So
you
might
need
to
think
well.
B
If
I've
got,
you
know
a
lot
of
users.
How
do
I
lock
them
down?
How
do
I
stop
them
from
getting
more
access
than
they
should
have?
But
in
some
cases
you
might
not
need
to
worry
about
that.
So
if
you
have,
for
example,
a
cluster
which
feeds
all
its
containers
through
a
cicd
pipeline
and
you
have
a
single
user,
then
you
probably
don't
need
to
spend
as
much
time
on
those
on
those
kind
of
attacks.
B
I'm
not
saying
in
an
ideal
world,
you
do
nothing.
But
realistically,
when
you
have
that
small
quantity
of
resources,
you
don't
start
there
and
with
the
other
one
with
compromised
containers,
if
you
have
no
externally
facing
applications
in
your
in
your
cluster,
maybe
they're
all
you
know
internal
batch
processing
applications
again,
maybe
you
don't
have
to
worry
as
much
about
compromised
container
attacks
and
you
can
focus
purely
on
that
kind
of
external
hardening
piece,
so
thinking
about
threat
modeling
is
useful.
B
B
Basically,
that
means
what
is
exposed
that
the
people
I'm
worried
about
attacking
can
get
to
and
can
try
and
compromise.
So
if
your
clusters
are
on
the
internet,
they
are
obviously
part
of
your
attack
surface
if
your
applications
are
on
the
internet.
They're
also
part
of
your
attack
surface,
but
there's
other
things.
That
might
be
less
obvious.
That
can
be
part
of
your
attack
surface,
which
would
be
things
like
container
registries.
B
If
you
have
a
container
register
you're
using
docker
hub
for
your
production
images,
your
docker
hub
accounts
are
now
part
of
your
attack
service.
If
an
attacker
gets
access
to
your
docker
hub
credentials,
they
can
push
malicious
images
which
are
then
pulled
down
into
your
production
clusters.
Your
ci
cd
systems,
you're
using
a
cloud-based
ci
cd
system.
That's
on
the
internet!
That
is
part
of
your
attack
service.
We
know
that
attackers
will
attack
ci
cd
systems.
We
know
that
they
try
to
compromise
them.
B
If
you
use
those,
then
you
need
to
concern
yourselves
with
both
how
you
get
access
to
those
crc
distance,
but
also
the
security
of
those
platforms
themselves,
because
you
know
they've
got
security
problems
too,
so
attack
surface
is
an
important
one.
So
that's
who's
going
to
attack
me.
That's
where
they're
going
to
attack
me
now
like
how
do
you
think
about
where
how
do
I
take
that
information
and
turn
it
into
where
I
start,
and
for
this
this
is
a
term.
This
is
possibly
the
most
important
slide
in
the
presentation.
B
B
B
What
you
want
to
try
and
avoid
is
a
situation
where
a
single
mistake,
like
a
single
loss
set
of
loss,
credentials
a
single
bug
in
a
program.
A
single
vulnerability
can
cause
a
security
incident
in
your
environment
that,
for
that,
that's
what
I'd
call
a
mess
up,
tolerance
of
one,
because
if
you
have
a
single
mess
up,
you
have
a
bad
security
incident.
B
What
you
want
to
try
and
do
is
get
to
the
point
where
it
would
require
two
three
four
incidents
all
to
happen
in
the
same
area
for
you
to
have
that
security
incident.
Give
me
a
I'll
give
you
a
worked.
Example
just
trying
to
make
that
a
bit
more
a
bit
more
real
say
you
have
a
kubernetes
cluster
right
and
you
have
it
on
the
internet
right.
The
api
server
is
exposed
to
the
internet.
B
Now
that
is
a
moderately
common
configuration
there's
about
several
hundred
thousand
kubernetes
clusters
sitting
live
on
the
internet
at
any
given
point
in
time
and
there's
some
search
engines.
You
can
go
to
look
around
them
all.
If
you
want
to
and
then
say
you
have
anonymous,
authentication
turned
on
on
your
api
server
again.
This
is
a
moderately
common
configuration.
Indeed,
it's
a
default
configuration
for
some
cloud
cluster
providers,
so
in
that
situation
you've
got
anonymous.
Author
api
server
on
the
internet.
B
If
you
make
one
our
back
mistake
so
see,
someone
applies
a
kubernetes
manifest
to
that
cluster.
That
says,
bind
cluster
admin
to
the
system.
Unauthenticated
group.
Now
that's
a
mistake.
That's
a
bad
mistake,
but
it's
a
single
mistake
and
if
you
have
that
configuration
and
then
you
bind
that
bad
manifest,
your
cluster's
gonna
have
a
bad
time
right.
The
attackers
will
find
it
quickly.
They
will
compromise
that
cluster.
B
B
At
that
point,
you
now
have
a
mess-up
tolerance
of
two,
because
someone's
going
to
need
a
set
of
credentials
and
they're
going
to
need
the
rights
to
do
it.
So
then,
now
you
have
two
things
that
probably
have
to
go
wrong
at
the
same
time
for
you
to
have
that
security
incident
then
say,
for
example,
you
take
your
api
server
off
the
internet.
B
You
don't
have
it
exposed
to
anyone
either
you
maybe
you
limit
the
source
ranges
that
can
get
to
it
or
you
put
it
behind
a
vpn
or
an
ssh
bastion
or
your
clouds
remote
access
service,
which
most
clouds
have
got
these
days.
You've
now
got
a
mess-up
tolerance
of
three
because
someone's
going
to
have
to
compromise
your
bastion
or
your
remote
access
service,
they're
going
to
have
to
get
valid
credentials
for
your
kubernetes
cluster
and
they're,
going
to
then
have
to
get
the
rights
to
actually
deploy
whatever
it
is
that
they
want
to
do
so.
B
Just
those
simple
steps
can
take
you
away
from
a
situation
where
a
single
vulnerability
in
the
kubernetes
api
server,
for
example,
you
know
there
could
be
a
cve
tomorrow
in
the
kubernetes
api
server.
If
your
clusters
are
sitting
there
on
the
internet,
you
might
have
a
mess-up
tolerance
of
one
and
that
could
obviously
be
very
bad.
So
for
my
money,
if
you're
getting
started,
that's
a
great
approach.
Think
about
the
places
where
one
mistake
could
give
you
a
security
incident
and
try
and
work
start
there
start
trying
to
get
those
numbers
up.
B
B
First
thing
to
do
is
to
think:
can
we
reduce
our
attack
surface,
you
know
and
then,
when
I
originally
showed
attack
surface
at
the
big
huge
castle,
with
all
the
different
ways
in
loads
of
windows
loads
of
doors,
can
we
reduce
that
if,
when
you
reduce
your
attack,
surface
you're,
lowering
the
number
of
places
where
you
have
to
spend
those
limited
resources
right,
so
you
don't
have
a
huge
number
of
resources.
Very
few
companies
do
you're
trying
to
say:
where
can
I
focus?
B
If
I
have
500
points
of
attack,
I
have
500
places.
I
have
to
worry
about
500
places
to
split
my
resources
across.
If
I
have
five,
I
can
focus
all
that
same
effort
in
five
places.
Therefore,
I
put
more
effort
per
place.
Lower
the
attack
surface,
the
better
you
can
focus
your
security
efforts
with
your
limited
resources,
the
more
chance
you'll
have
of
avoiding
something
bad
happening.
B
How
can
we
do
that,
though?
Let's
talk
about
some
of
the
real,
you
know
things
you
can
do
for
that,
we'll
start
off
with
quick
wins.
What
are
the
quick
ones,
the
things
those
like
you
want
one
thing
to
do:
what
can
you
do?
Is
the
one
thing
don't
put
your
clusters
on
the
internet,
some
people
who
are
watching
this?
Maybe
thinking?
Well,
that's
obvious!
Why
would
I
put
my
kubernetes
api
server
on
the
internet?
Other
people
will
be
thinking
all
my
api
servers
are
on
the
internet.
B
B
If
your
cluster
api
server
is
on
the
internet,
you
potentially
have
always
got
a
mess
up,
tolerance
of
one
because
a
node
a
zero
day
attack
an
unex,
unpatched
vulnerability,
the
kubernetes
api
server
and
your
cluster
could
be
compromised
getting
that
off
the
internet.
If
you
don't
need
it,
you
know
you
can
limit
ip
address
ranges.
If
you
need
systems
to
be
able
to
talk
to
it,
you
can
put
it
behind
a
bastion,
a
vpn
server.
There's
options.
B
You've
got
there,
but
if
you
can
get
that
off
the
internet,
you're
potentially
you're,
reducing
your
tax
office
for
sure
and
you
get
their
mess-up
tolerance
away
from
being
one.
That's
the
first
thing
I
think
that's
worth
doing.
If
you
can
new
clusters
apps
easier,
existing
clusters,
you
might
need
to
look
at
what
might
be
using
that
and
rework.
B
Second
one
use
managed
kubernetes
if
you
can,
when
you
use
a
managed
service
so
like
something
like
gke,
aks
eks,
you
get
the
shared
responsibility
model
where
the
cloud
provider
will
take
on
some
of
the
responsibilities
for
security,
so
with
managed
kubernetes.
That
typically
means
that
you
no
longer
have
to
worry
about
those
control,
plane
nodes.
You
don't
need
to
worry
about
patching
your
control
plane
either
because
both
of
those
things
should
be
done
for
you
by
the
cloud
service
provider.
B
So
that's
reducing
your
attack
surface
because
it
means
someone
else's
has
to
manage
that
now.
Obviously,
you're
trusting
that
they
will
handle
that,
but
it
means
it's
something
else
you
don't
have
to
worry
about.
You
don't
have
to
think
about
right.
You
know
how
have
I
hardened
my
api
server
nodes?
Have
I
managed
to
patch
the
api
server
et
cetera,
et
cetera?
You
can
let
them
handle
that.
B
B
B
If
you,
therefore
you
can
remove
it,
so
you
can
remove
it
at
the
pod
level.
You
can
tell
the
service
account
not
to
mount
the
service
account
token
by
default
and
then
only
mount
it
where
specifically
required,
and
you
see
well
by
default.
It
doesn't
have
a
lot
of
rights,
and
that
is
true,
but
I've
seen
third
party
products
or
kubernetes
that
will.
I
saw
one,
for
example,
that
bound
as
part
of
its
installation
mechanism
it
bound
the
default
service,
account
token
in
the
default
namespace
to
cluster
admin.
B
That
means
that
any
pod
that
was
in
that
namespace
and
use
the
default
service
account
token
had
cluster
admin
automatically
and
any
person
who
could
create
a
pod
in
the
default
namespace
got
cluster
admin
for
their
workloads,
mess
up
tolerance
of
one
again.
If
you
don't
have
that
surface
account
token,
and
you
apply
that
manifest,
you
are
not
going
to
have
as
bad
a
time
of
it.
It's
less
likely
that
someone
will
be
able
to
compromise
that.
It
also
gives
you
time
to
notice.
B
B
So
there's
also
some
things
which
are
high
impact
but
harder.
These
are
things
which
aren't
as
easy
to
do
but
which,
if
you
can
do
them,
will
have
a
big
impact
on
your.
In
this
case.
Your
attack
surface
default,
deny
network
policies
by
default.
Every
kubernetes
workload
in
a
cluster
can
talk
across
the
container
network
to
every
other
workload.
B
This
means
that
if
someone
can
compromise
one
container,
they
they
can
scan
the
whole
container
network.
So
when
I
was
a
pen
tester
and
I
did
a
compromised
container
assessment,
so
when
I
start
with
the
comprised
container,
my
very
first
thing
to
do
is
install
a
port
scanning
tool.
Scanner
in
the
entire
container
network,
looking
for
other
services
to
attack,
and
what
I
typically
found
was
that
people
would
assume
that
things
installed
inside
the
container
network
were
on
a
trusted
environment
and
they
maybe
didn't
have
authentication
turned
on
by
default.
B
So
that
gave
me
other
things
to
go
and
attack.
If
you
can
turn
on
default
and
deny
network
policies,
this
is
harder
because
it
means
when
you're
developing
applications.
You
need
to
think
what
other
services
does
this
application
communicate
to,
and
then
you
need
to
write
network
policies
that
imply
that
that
make
that
the
case
so
that
you
know
that
when
you
deploy
it
you'll
get
the
network
policies.
B
You
need
to
talk
to
other
systems,
so
it
is
harder
to
do,
but
it
does
have
a
big
security
benefit
if
you're
worried
about
compromised
containers
again,
if
you're
not
worried
about
that
scenario,
you
maybe
don't
need
to
do
this
as
much
or
as
early
in
your
process.
But
if
you
do
it's
a
good
good
change
to
make.
B
So,
in
addition
to
reducing
the
attack
attack
surface,
we
can
also
harden
things
up.
We
can
improve
on
the
security
defaults
that
are
given
to
us
by
our
container
runtimes
and
by
kubernetes
in
ways
that
will
essentially
make
it
harder
for
attackers
we'll
improve
our
mess-up
tolerance.
You
know
I
I'm
gonna,
make
it
more
likely.
Our
clusters
will
be
secure
from
day
to
day.
B
Again,
let's
look
at
some
quick
ones.
Let's
look
at
things.
You
can
do
easily
that
shouldn't
have
any
impact
on
your
working
practices
or
your
existing
clusters
or
applications,
but
will
improve
things
first
thing
to
talk
about
is
security,
context
and
workloads.
This
is
one
of
as
an
application
if
you're
an
application,
developer
or
you're
an
application
owner.
B
One
of
the
best
things
you
can
do
is
set
security
contacts
on
your
workloads
because
you're
essentially
making
it
easier
for
you
you're,
reducing
the
privileges
given
to
the
application
when
it's
deployed-
and
you
are
helping
also-
if
you
then
go
on
to
do
things
like
admission
control,
you're,
making
it
easier
for
that
to
happen,
because
the
applications
already
have
the
security
settings
they
need
in
place.
So
everyone's
clear
about,
what's
required
for
this
application,
a
couple
of
easy
ones
to
set
security
context
privileged
false,
privileged
containers
are
very
dangerous.
B
You
should
never
use
privileged
containers
unless
you
absolutely
have
to
explicitly
setting
this
as
false.
Just
makes
it
clear
that
you
don't
need
that,
and
you
don't
want
it.
It
means,
if
you're
using
infrastructure's
code
scanning
tools
that
you
can
clearly
see
which
ones
have
got
it,
which
ones
don't
the
default
is
that
it
shouldn't
be
on.
So
it's
not
as
bad
if
you
don't
have
it
set,
but
I
always
recommend
is
a
nice
easy.
You
know
if
you're
doing
templates
for
your
application
manifests
put
in
that
security
context.
B
Another
one
to
set
that
should
be
relatively
easy.
Relatively
low
risk
is
allowed
privilege
escalation
false
this
one's
not
on
by
default.
So
this
is
worth
setting.
What
this
basically
says
is,
if
I
start
my
container
as
a
non-root
user,
don't
allow
it
to
get
more
privileges
once
it's
running,
don't
allow
it,
for
example,
to
pseudo
up
to
root
that
should
be
fairly
safe.
I
don't
think
I've
ever
seen
an
application
that
starts
with
low
privilege
and
then
tries
to
get
more
privilege
inside
the
container.
B
I've
seen
applications
that
do
the
reverse,
so
maybe
they
start
as
a
privileged
user
and
then
drop
to
an
ordinary
user,
like
I
think
nginx
does
that,
but
I've
never
seen
the
reverse,
so
this
should
be
relatively
safe.
Shouldn't
be
a
problem.
If
you
put
this
in
your
application,
manifest
templates,
you
have
a
setting
which
should
improve
your
security.
B
In
this
section,
there's
quite
a
few
things
that
are
harder
but
high
impact
things
that
are,
you
know
if
you
have
that
extra
resource,
maybe
you've
got
some
additional
time
or
you're
planning
something
out
for
the
future,
definitely
worth
considering
security
context
and
workloads.
Previously
we
talked
a
little
bit
about
some
easy
settings.
Some
things
that
aren't
super
complicated
shouldn't
be
impactful.
There
are
other
things
you
can
set
which
do
require
more
effort,
but
are
significant
benefits.
B
Don't
run
as
route
containers
running
as
root
is
not
a
great
default
from
a
security
standpoint,
but
they
do
so
you
you
need
to
do
the
work
for
this
one.
So
essentially
you
need
to
work
with
when
you're
developing
your
container
images
to
have
them
run
as
a
non-root
user,
so
setting
a
user
making
sure
that
the
application
can
build
and
run
okay
when
it's
not
root.
B
When
you've
done
that,
then
you
can
set
these
settings
in
security
context
to
say
what
user
id
and
what
group
they're
going
to
run
as
don't
explicitly
use
that
ten
thousand
one
that's
just
one.
I
picked
as
an
example.
The
reason
this
is
important
is,
if
you
run
your
containers,
there
is
more
of
a
chance
of
a
breakout.
B
Whilst
your
container
run
time
like
docker
will
constrain
routes.
So
it's
not
completely
unconstrained.
There
have
been
several
cves
now
where
the
first
line
of
the
cv
is.
This
only
works.
If
the
container
runs
his
room
right,
so
it
will
reduce
the
risk.
If
there's
a
cve
and
you've
got
that
mess-up
tolerance,
you
say
well,
if
I'm
not
running
any
my
container's
root.
This
is
less
likely
that
this
can
ever
be
exploited
in
some
cases
actually
might
not
be
possible
to
exploit.
B
So
this
is
a
good
hardening
setting,
but
it
does
require
more
work
because
you
have
to
look
at
it
for
each
application
and
make
sure
that
it
can
run
as
a
non-root
user
read-only
root
file
system,
setting
it
to
true
in
the
security
context.
So
here
containers
are
meant
to
be
ephemeral.
Right
containers
are
not
meant
to
store
state
inside
the
running
container
they're,
not
storing
persistent
data,
so
you
should
be
able
to
set
the
read-only
route
at
the
root
file
system.
B
B
What
an
attacker
will
do.
Typically,
when
they
compromise
a
container,
is
they
will
put
their
tools,
some
sort
of
binary?
Some
sort
of
you
know
malware
into
the
container,
so
they
can
then
carry
on
doing
what
they
want.
If
they
try
to
do
that,
and
it
fails
because
you
have
a
read-only
root
file
system,
it
will
either
slow
them
down
while
they
search
around
looking
for
the
writable
file
path
or
it
might
stop
them.
If
it's
an
automated
scanner,
it
tries
to
drop
the
tool,
it
doesn't
work.
B
B
If
your
applications
don't
need
those,
you
can
drop
them
all
in
security
context,
say
drop.
All
don't
give
me
any
of
these
rights
that
I
don't
need
doctor
chooses
like
a
kind
of
what
they
thought,
what
they
felt
they're.
Probably
right
was
the
same
default
that
would
work
for
everyone,
but
a
lot
of
applications,
especially
if
you're
not
running
a
route,
don't
need
any
capabilities.
B
Also
until
recently,
you
might
have
needed
capabilities
to
do
things
like
bind
low
ports
so
to
bind
like
port
80.
You
had
to
have
cap
net,
bind
you
don't
anymore,
because
in
docker
it
sets
a
cis
cattle
which
says
you
can
you
can
bind
unprivileged
ports,
low
ports
and
in
kubernetes
122
and
above
you
also
have
exposed
that
so
you
can
set
it
in
security
context
to
say,
allow
a
non-root
user
to
bind
the
low
ports.
B
And
if
you
do
that,
then
you
can
do
this,
get
rid
of
all
your
capabilities
and
it's
going
to
make
attackers
life
again
harder
if
they
land
in
a
compromised
container,
they're
going
to
have
less
chance
of
breaking
out
to
the
underlying
machine
and
then
giving
you
that
bad
security
incident.
But
it
does
require
a
bit
more
work.
You
do
have
to
think
do
any
of
my
containers
expect
to
have
a
specific
capability.
B
Some
other
things
harder,
but
absolutely
worth
doing
admission
control,
so
security
context
is
a
voluntary
mechanism.
Every
manifest
can
set
it
if
you're
worried
about
either
compromised
user
credentials
or
you're
worried
about.
Potentially
you
want
to
restrict
the
rights
of
your
users
to
do
specific
things,
you're
going
to
need
to
mandate
those
controls.
You
can't
rely
on
voluntary
security
context
and
to
do
that,
you
need
some
form
of
admission
control
in
the
past.
We
would
have
said
pod.
Security
policy
would
have
been
the
approach
to
take
as
that's
being
deprecated.
B
You
should
be
looking
now
either
to
the
new
pod
security
admission
controller,
which
is
coming
into
beta
in
1.23,
or
look
at
external
ones
like
oppa
or
kyverno.
Things
like
that
use
those
to
enforce
your
policies.
I
use
those
to
enforce
things
like
read:
only
root
file
systems,
non-root
users
and
stuff
like
that
again,
this
is
in
the
high
impact
by
harder,
because,
fundamentally,
this
is
going
to
require
you
to
probably
go
and
get
piece
of
third
party
software
to
implement.
B
It
make
sure
the
rules
are
running
right,
make
sure
it
doesn't
impact
your
clusters.
But
if
you
have
a
multi-user
cluster
and
you
are
worried
about
that
threat
model,
you
should
do
this
again.
If
you're
not
worried
about
that
thread
model,
you
can
probably
always
do
this
as
early.
You
know
still,
ideally
would
be
good
to
have
but
move
it
down
the
priority
list
a
while
this
privilege
are
back.
This
is
another
one.
B
Only
really
matters
if
you've
got
again
lots
of
users
in
your
cluster
and
you're
concerned
about
restricting
their
rights
and
making
sure
they
can't
do
things
you
know
they
shouldn't
be
able
to.
This
is
quite
difficult,
and
one
of
the
reasons
why,
if
someone
says
to
me,
I
want
you
know
a
really
tightly
secured
cluster.
I
say
we'll:
try
not
to
give
people
kubernetes
api
access
kubernetes.
Our
back,
has
quite
a
lot
of
kind
of
like
edge
cases,
things
which
are
maybe
not
intuitive
but
could
cause
security
leaks.
B
If
I
was
giving
simple
advice
about
our
back,
the
three
things
and
the
two
things
I
would
say
is
avoid
cluster
admin.
Don't
give
people
cluster
admin,
that's
a
terrible
idea,
because
it
allows
them
to
do
everything
and
you
probably
didn't
need
them
to
do
absolutely
everything
in
your
cluster.
It
also
means,
if
you
have
a
mistake,
someone
mistypes
something,
but
you
know
they
delete
namespaces.
Well,
if
you
didn't
give
them
the
right
to
delete
namespaces,
they
can't
do
that.
B
The
other
thing,
I
would
say,
is
try
to
avoid
the
built-in
cluster
rules,
things
like
view
and
edit
because
they're
they're
quite
they're,
not
very
fine-grained,
and
they
might
give
you
access
to
things
that
you
didn't
expect
and
then
to
give
access
to
and
give
rights.
You
didn't
expect,
always
when
you're
doing
our
back,
try
and
think
what
does
this
person
actually
need
to
do?
Or
what
does
the
service
go
actually
need
to
do
and
give
it
as
fine
grain
as
possible?
B
It
is
in
the
harder
category
because
that
does
require
work,
but
it's
important
if
you're
worried
about
the
the
kind
of
you
know,
user
access
plate
of
things
last
one
I
would
mention-
is
internal
container
registry.
When
I
was
a
pen
tester,
the
finding
I
pretty
much
always
gave
in
every
single
report
was:
you
are
using
images
that
are
from
random
users
on
docker
hub
right.
You've
downloaded
not
one
of
the
official
images,
but
some
person's
random
image
now
doppler
hub
is
entirely
uncurated
outside
of
the
kind
of
official
and
vendor-based
images.
B
If
you're
pulling
those
images,
they
could
be
anything,
and
it
also
means
that
the
third-party
developer,
whose
image
you're
pulling
their
credential
management,
is
now
part
of
your
attack
service,
because
if
they
lose
their
access
to
that
account,
their
password
gets
stolen.
Their
accounts
get
stolen.
That's
now
your
problem,
because
you're
pulling
their
image
into
your
cluster
the
best
way
to
get
around
that
is
to
have
an
internal
internally
curated,
set
of
container
images
that
you
manage
yourself
in
your
own
container
registry.
B
It
doesn't
need
to
necessarily
be
on-prem,
obviously
in
the
cloud,
but
that's
something
that
you
manage,
that
that
you
control
and
that
gets
away
from
that
problem,
because
then
what
you
can
do
is
use
admission
control
to
say
only
allow
images
that
come
from
our
internal
container
registry
and
that's
going
to
essentially
harden
the
setup
quite
a
bit.
But
again
this
is
more
work.
You
have
to
implement
container
registry,
you
have
to
manage
access
to
it.
You
have
to
get
all
the
tools
and
everything
else
set
up
for
it.
B
But
for
my
money,
that's
somewhere,
that's
worth
looking
into
so
couple
more
resources,
a
couple
of
tools
which
could
be
useful
when
you
are
doing
your
when
you're
doing
this
kind
of
work.
First
one
is:
is
these
are
open
source
tools?
First,
one
is
cubebench.
Qbench
allows
you
to
scan
your
clusters
and
compare
them
to
the
cis
kubernetes
benchmark.
So
just
a
quick
way
of
saying
what
settings
do
I
have
that
I
might
want
to
look
at
with
the
cis
benchmarks.
B
One
thing
I
would
say
is:
don't
necessarily
think
I
have
to
do
everything
on
this
benchmark
right.
That's
probably
not
necessarily,
you
know
realistic,
but
it's
definitely
somewhere
to
start.
The
other
tool
is
trivi.
You
may
know
trivia
as
a
vulnerability
scanning
tool
so
for
scanning
images
for
outdated
software.
It
also
does
iac
scanning,
so
you
can
scan
your
kubernetes
manifests
and
you
can
come
back
with
like
things
that
are
wrong,
like
you've
got
privilege
set
or
you
haven't
proper
capabilities
and
that's
a
tool
that
can
be
used
on
any
machine.
B
So
it
means
that
developers
when
they're
writing
manifests
can
scan
their
manifest
against
trivia
and
say
what
do
I
need
to
consider
in
terms
of
actually
securing
that
down
and
you
can
customize
the
policies
as
well,
so
conclusion
think
about
your
threat
model
you're,
trying
to
think
you've
got
limited
resources.
Think
about
who
is
it
you're,
worried
about?
Who
do
you
think's
going
to
attack
you
and
think
about?
Where
can
they
attack
you?
B
B
A
B
I'm
not
sure
I
can
think
of
an
immediate
impact.
I
mean
there
might
be
something
with
availability
where
it's
going
to
improve
things
by
you
know
you
have
less
likelihood
of
getting
denial
of
service.
That's
the
only
one
that
kind
of
springs
to
mind.
That's
a
tricky
one
I'll!
Maybe
give
that
some
thought.
A
B
It
does
a
decent
job
of
into
isolation,
but
I
wouldn't
rely
on
it
against
hostile
tenants
and
we've
seen
several
cvs.
There's
been
cvs
and
run
c
that
have,
you
know
essentially
allowed
you
to
break
out
to
the
underlying
host
file
system.
It's
quite
a
complex
stack
and
there's
all
these
layers.
You
know
you
run
c
container
d,
then
you've
got
kubernetes
and
they
all
need
to
line
up
their
security
primitives,
which
is
a
challenge
because
you
have
different
groups
managing
each
of
those.
C
Just
one
question:
we,
you
talked
earlier
about
vulnerabilities
and
and
so
on,
and
it
seems
like
always.
I
think,
as
you
said,
almost
all
containers
have
some
sort
of
vulnerability
or
will
have
some
sort
of
vulnerability,
any
advice
on
kind
of
in
or
watching
where
to
start
with
that,
do
you
do
you
threaten
all
those
vulnerabilities?
How
do
you
start
categorizing
them
in.
B
B
Think
the
thing
I
would
say
is
is
the
the
best
thing
people
can
do
if
they're
getting
started
for
container
variability
is
try
not
to
install
software,
you
don't
need
in
containers,
less
software,
the
less
you
know
the
less
vulnerabilities,
the
easier
it'll
be
to
pick
ones.
Then,
if
you've
got
time
and
there's
ones,
you
can't
easily
patch
look
for
things
that
are
remote
exploitable.
B
You
know,
cvs
escorts
will
have
this
thing
about
whether
they
can
be
exploited
remotely
they're,
not
always
perfect,
because
they
don't
know
about
containers
when
they
write
these
scores,
so
it
might
not
be
applicable.
So
it
is
a
bit
tricky
because
you
have
to
dive
into
each
vulnerability
and
that's
fine
if
you've
got
five,
but
if
you've
got
five
thousand
you're
not
going
through
each
one
going
to
do
that's
why
I'll
say
easiest
thing,
try
and
get
rid
of
any
software.